perm filename COMMON.9[COM,LSP] blob
sn#838394 filedate 1987-04-12 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00853 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00118 00002
C00119 00003 ∂29-Jul-86 0328 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Re: exit-to-system
C00122 00004 ∂29-Jul-86 0623 Moon@RIVERSIDE.SCRC.Symbolics.COM Proposal #7: TYPE-SPECIFIER-P
C00125 00005 ∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Some easy ones (?)
C00127 00006 ∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #8: Clarifications to DEFCONSTANT
C00132 00007 ∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #14: THE and VALUES
C00137 00008 ∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #11: Contents of Tagbody
C00141 00009 ∂29-Jul-86 0643 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #9: Variable Name Conflicts
C00147 00010 ∂29-Jul-86 0643 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #13: Structure Sharing in Arguments
C00156 00011 ∂29-Jul-86 0644 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Proposal about lambda-list params
C00158 00012 ∂29-Jul-86 0649 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5 status
C00161 00013 ∂29-Jul-86 0652 NGALL@G.BBN.COM Re: Proposal about lambda-list params
C00164 00014 ∂29-Jul-86 0658 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5 status
C00167 00015 ∂29-Jul-86 1123 DCP@QUABBIN.SCRC.Symbolics.COM Re: PARSE-BODY
C00170 00016 ∂29-Jul-86 1215 @SU-SCORE.ARPA,@REAGAN.AI.MIT.EDU:MLY@AI.AI.MIT.EDU Re: PARSE-BODY
C00184 00017 ∂29-Jul-86 1218 Miller.pa@Xerox.COM Re: Proposal about lambda-list params
C00187 00018 ∂29-Jul-86 1219 DCP@QUABBIN.SCRC.Symbolics.COM Staus of proposals 10, 11, and 12
C00190 00019 ∂29-Jul-86 1220 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA Re: Proposal #7 Status: TYPE-SPECIFIER-P
C00196 00020 ∂29-Jul-86 1255 RPG Yapper of the Month Club
C00197 00021 ∂29-Jul-86 1456 FAHLMAN@C.CS.CMU.EDU Proposed moratorium (clarification)
C00199 00022 ∂29-Jul-86 1734 pyramid!bein@SUN.COM closing standard channels
C00201 00023 ∂29-Jul-86 1835 NGALL@G.BBN.COM Re: Proposal #9: Variable Name Conflicts
C00204 00024 ∂29-Jul-86 1848 NGALL@G.BBN.COM Re: Staus of proposals 10, 11, and 12
C00207 00025 ∂29-Jul-86 1854 FAHLMAN@C.CS.CMU.EDU Proposal #8: Clarifications to DEFCONSTANT
C00210 00026 ∂29-Jul-86 1920 FAHLMAN@C.CS.CMU.EDU Proposal #9: Variable Name Conflicts
C00213 00027 ∂30-Jul-86 0640 MASINTER.PA@Xerox.COM declarations in macrolet puzzle
C00215 00028 ∂30-Jul-86 0705 RAM@C.CS.CMU.EDU Declarations in MACROLET
C00217 00029 ∂30-Jul-86 1001 gls@Think.COM Motivation for PARSE-BODY
C00219 00030 ∂30-Jul-86 1049 Masinter.pa@Xerox.COM Re: Motivation for PARSE-BODY
C00222 00031 ∂30-Jul-86 1137 gls@Think.COM Re: Proposal about lambda-list params
C00224 00032 ∂30-Jul-86 1252 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
C00231 00033 ∂30-Jul-86 1259 berman@vaxa.isi.edu Conference
C00233 00034 ∂30-Jul-86 1330 berman@vaxa.isi.edu Conference
C00235 00035 ∂30-Jul-86 1339 FAHLMAN@C.CS.CMU.EDU Handout at Lisp Conference
C00243 00036 ∂30-Jul-86 1356 FREEMAN@SUMEX-AIM.ARPA Re: Proposal #9: Variable Name Conflicts
C00246 00037 ∂30-Jul-86 1400 jbarnett@nrtc Re: Proposal #9 Status: Variable Name Conflicts
C00248 00038 ∂30-Jul-86 1418 FAHLMAN@C.CS.CMU.EDU Proposal #9: Variable Name Conflicts
C00250 00039 ∂30-Jul-86 1434 Gregor.pa@Xerox.COM Re: Motivation for PARSE-BODY
C00252 00040 ∂30-Jul-86 1719 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #5 (aside)
C00254 00041 ∂30-Jul-86 1720 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14
C00270 00042 ∂30-Jul-86 1720 BSG@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: exit-to-system
C00273 00043 ∂30-Jul-86 1720 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Status of declare UNSPECIAL
C00277 00044 ∂30-Jul-86 2018 FAHLMAN@C.CS.CMU.EDU Proposal #5 (aside)
C00281 00045 ∂31-Jul-86 0451 @MCC.COM,@HAL.MCC.DialNet.Symbolics.COM:Loeffler@[10.3.0.62] Re: exit-to-system
C00284 00046 ∂31-Jul-86 1143 alatto@cc5.bbn.com Re: #13, #14
C00291 00047 ∂31-Jul-86 1502 @QUABBIN.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM Re: Staus of proposals 10, 11, and 12
C00295 00048 ∂31-Jul-86 1506 @QUABBIN.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM Proposal #5 (aside)
C00298 00049 ∂31-Jul-86 1514 hoey@nrl-aic Proposal #9: Fast testing in PROGV
C00300 00050 ∂31-Jul-86 1533 @YUKON.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM Re: Proposal #9 Status: Variable Name Conflicts
C00304 00051 ∂31-Jul-86 1827 FAHLMAN@C.CS.CMU.EDU Proposal #9 Status: Variable Name Conflicts
C00306 00052 ∂31-Jul-86 1848 FAHLMAN@C.CS.CMU.EDU What's going on?
C00309 00053 ∂31-Jul-86 1943 NGALL@G.BBN.COM Re: declarations in macrolet puzzle
C00311 00054 ∂31-Jul-86 1949 NGALL@G.BBN.COM Re: Declarations in MACROLET
C00313 00055 ∂31-Jul-86 2155 FAHLMAN@C.CS.CMU.EDU Japanese Subset Proposal
C00315 00056 ∂31-Jul-86 2211 KMP@YUKON.SCRC.Symbolics.COM Comments on DCP's revised &BODY proposal
C00320 00057 ∂31-Jul-86 2229 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
C00322 00058 ∂31-Jul-86 2230 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM QUIT
C00334 00059 ∂01-Aug-86 0357 hpfclp!hpfcjrd!diamant@hplabs.HP.COM Proposal #13: Structure Sharing in Arguments
C00337 00060 ∂01-Aug-86 0536 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #9: Fast testing in PROGV
C00340 00061 ∂01-Aug-86 0955 hoey@nrl-aic Proposal #9: Fast testing in PROGV
C00343 00062 ∂01-Aug-86 0956 gls@Think.COM Proposal #9: Fast testing in PROGV
C00346 00063 ∂01-Aug-86 1533 Hadden.CSCES@HI-MULTICS.ARPA Re: Proposal #9 Status: Variable Name Conflicts
C00348 00064 ∂04-Aug-86 1300 Dan@Think.COM ignore this message
C00349 00065 ∂05-Aug-86 0908 pyramid!bein@hplabs.HP.COM synonym streams..
C00351 00066 ∂05-Aug-86 1111 Masinter.pa@Xerox.COM Re: synonym streams..
C00353 00067 ∂06-Aug-86 1100 @QUABBIN.SCRC.Symbolics.COM,@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM DPB, DPBS, something like that
C00356 00068 ∂06-Aug-86 1724 @QUABBIN.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM Re: synonym streams..
C00358 00069 ∂06-Aug-86 1904 SOLEY@XX.LCS.MIT.EDU DPB, DPBS, something like that
C00360 00070 ∂09-Aug-86 2041 mips!earl@glacier.stanford.edu :allow-other-keys query
C00362 00071 ∂09-Aug-86 2104 FAHLMAN@C.CS.CMU.EDU :allow-other-keys query
C00364 00072 ∂09-Aug-86 2320 Hvatum.DLAB@MIT-MULTICS.ARPA &rest destruction
C00371 00073 ∂10-Aug-86 1205 FAHLMAN@C.CS.CMU.EDU &rest destruction
C00375 00074 ∂10-Aug-86 1350 shebs%utah-orion@utah-cs.arpa TAGBODY vs LABELS
C00377 00075 ∂10-Aug-86 2132 RAM@C.CS.CMU.EDU TAGBODY vs LABELS
C00379 00076 ∂10-Aug-86 2327 masinter.PA@Xerox.COM tagbody using labels
C00382 00077 ∂11-Aug-86 0916 gls@Think.COM ,',@
C00383 00078 ∂11-Aug-86 1120 gls@Think.COM tagbody using labels
C00384 00079 ∂11-Aug-86 2258 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM TAGBODY vs LABELS
C00388 00080 ∂11-Aug-86 2307 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM :allow-other-keys query
C00391 00081 ∂12-Aug-86 1246 snyder%hplsny@hplabs.HP.COM Re: Proposal #7 Status: TYPE-SPECIFIER-P
C00396 00082 ∂13-Aug-86 1051 Moon@QUABBIN.SCRC.Symbolics.COM Proposal #7: TYPE-SPECIFIER-P
C00401 00083 ∂13-Aug-86 2151 LOOSEMORE@UTAH-20.ARPA question about subtypep
C00403 00084 ∂14-Aug-86 0353 RAM@C.CS.CMU.EDU question about subtypep
C00406 00085 ∂14-Aug-86 0559 Hvatum.DLAB@MIT-MULTICS.ARPA &rest destruction
C00409 00086 ∂14-Aug-86 1444 Pavel.pa@Xerox.COM More words on the scoping of declarations
C00429 00087 ∂14-Aug-86 1602 RAM@C.CS.CMU.EDU More words on the scoping of declarations (FTYPE)
C00431 00088 ∂15-Aug-86 0734 cvfong@mitre.ARPA drop out
C00432 00089 ∂18-Aug-86 1101 RAM@C.CS.CMU.EDU More words on the scoping of declarations
C00435 00090 ∂18-Aug-86 1459 @DIAMOND.S4CC.Symbolics.COM:File-Server@DIAMOND.S4CC.Symbolics.COM string-/=, etc.
C00437 00091 ∂18-Aug-86 1725 HEDRICK@RED.RUTGERS.EDU close on synonym streams, etc
C00439 00092 ∂18-Aug-86 1825 franz!fizzy!jkf@kim.Berkeley.EDU Re: synonym streams..
C00443 00093 ∂19-Aug-86 1045 ACUFF@SUMEX-AIM.ARPA Re: synonym streams..
C00445 00094 ∂19-Aug-86 1240 KMP@STONY-BROOK.SCRC.Symbolics.COM close on synonym streams, etc
C00451 00095 ∂19-Aug-86 1556 pyramid!bein@hplabs.HP.COM streams ...
C00456 00096 ∂19-Aug-86 1827 sridhar%tekecs.tek.csnet@CSNET-RELAY.ARPA documentation strings in BOA constructors ?
C00458 00097 ∂19-Aug-86 1840 RAM@C.CS.CMU.EDU documentation strings in BOA constructors ?
C00461 00098 ∂20-Aug-86 0540 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM "fonted" characters in CL
C00465 00099 ∂20-Aug-86 1040 RICE@SUMEX-AIM.ARPA Defstruct and Documentation.
C00466 00100 ∂22-Aug-86 1333 @MC.LCS.MIT.EDU,@SEBASTIAN.THINK.COM:gls@AQUINAS.THINK.COM 1986 Lisp conference bibliography
C00505 00101 ∂25-Aug-86 1059 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Defstruct and Documentation.
C00507 00102 ∂25-Aug-86 1105 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM question about subtypep
C00511 00103 ∂25-Aug-86 1117 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: synonym streams..
C00513 00104 ∂25-Aug-86 1201 RAM@C.CS.CMU.EDU question about subtypep
C00516 00105 ∂25-Aug-86 2029 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA More words on the scoping of declarations
C00521 00106 ∂25-Aug-86 2154 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA "fonted" characters in CL
C00527 00107 ∂26-Aug-86 0057 pyramid!bein@hplabs.HP.COM re: synonym streams..
C00535 00108 ∂26-Aug-86 0653 preece%ccvaxa@gswd-vms.ARPA Re: More words on the scoping of dec
C00538 00109 ∂26-Aug-86 0904 RAM@C.CS.CMU.EDU More words on the scoping of declarations
C00541 00110 ∂27-Aug-86 0925 Gregor.pa@Xerox.COM Fixing optional arguments?
C00544 00111 ∂27-Aug-86 1058 FAHLMAN@C.CS.CMU.EDU Fixing optional arguments?
C00546 00112 ∂27-Aug-86 1846 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Fixing optional arguments?
C00550 00113 ∂28-Aug-86 1122 Gregor.pa@Xerox.COM Re: Fixing optional arguments?
C00553 00114 ∂28-Aug-86 1216 RAM@C.CS.CMU.EDU Fixing optional arguments?
C00555 00115 ∂29-Aug-86 0956 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: Fixing optional arguments?
C00558 00116 ∂31-Aug-86 1341 LOOSEMORE@UTAH-20.ARPA question about pprint, *print-pretty*
C00560 00117 ∂02-Sep-86 0909 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM question about pprint, *print-pretty*
C00564 00118 ∂02-Sep-86 0909 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM question about pprint, *print-pretty*
C00568 00119 ∂02-Sep-86 1149 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM PRINT
C00571 00120 ∂02-Sep-86 1234 Masinter.pa@Xerox.COM Re: close on synonym streams, etc
C00574 00121 ∂03-Sep-86 1409 RICE@SUMEX-AIM.ARPA Documentation strings and function.
C00577 00122 ∂03-Sep-86 1636 VERACSD@A.ISI.EDU Deletion from Mailing-List
C00578 00123 ∂03-Sep-86 1810 FAHLMAN@C.CS.CMU.EDU Documentation strings and function.
C00580 00124 ∂03-Sep-86 1929 @WAIKATO.S4CC.SYMBOLICS.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM Documentation strings and function.
C00585 00125 ∂04-Sep-86 0739 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Documentation strings and function.
C00588 00126 ∂04-Sep-86 0853 allen@bfly-vax.bbn.com Re: Documentation strings and function.
C00590 00127 ∂04-Sep-86 0945 FAHLMAN@C.CS.CMU.EDU Documentation strings and function.
C00593 00128 ∂04-Sep-86 1038 LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU Problems with Notation in CLtL
C00597 00129 ∂04-Sep-86 1102 allen@bfly-vax.bbn.com Re: Documentation strings and function.
C00599 00130 ∂04-Sep-86 1222 FAHLMAN@C.CS.CMU.EDU Documentation strings and function.
C00601 00131 ∂04-Sep-86 1421 Bobrow.pa@Xerox.COM Re: Documentation strings and function.
C00603 00132 ∂04-Sep-86 1421 Bobrow.pa@Xerox.COM Re: Documentation strings and function.
C00605 00133 ∂04-Sep-86 1518 @ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: Documentation strings and function.
C00608 00134 ∂04-Sep-86 1639 @ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: Documentation strings and function.
C00610 00135 ∂04-Sep-86 1842 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Re: Documentation strings and function.
C00615 00136 ∂05-Sep-86 1236 gls@Think.COM Problems with Notation in CLtL
C00617 00137 ∂05-Sep-86 2358 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Programmer Notes
C00621 00138 ∂07-Sep-86 1646 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM #+FOO:BAR
C00623 00139 ∂08-Sep-86 0909 @ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Programmer Notes
C00625 00140 ∂11-Sep-86 0839 MATT@LL.ARPA
C00626 00141 ∂12-Sep-86 0311 bradley@Think.COM An example of where setf does not do what I want.
C00628 00142 ∂12-Sep-86 0814 FAHLMAN@C.CS.CMU.EDU An example of where setf does not do what I want.
C00632 00143 ∂12-Sep-86 0844 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM An example of where setf does not do what I want.
C00636 00144 ∂12-Sep-86 0942 fateman@renoir.Berkeley.EDU OPS-5 in Common Lisp
C00638 00145 ∂12-Sep-86 1030 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM An example of where setf does not do what I want.
C00641 00146 ∂13-Sep-86 1846 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Locally
C00644 00147 ∂14-Sep-86 1337 FAHLMAN@C.CS.CMU.EDU Locally
C00647 00148 ∂14-Sep-86 1543 Gregor.pa@Xerox.COM Portable CommonLoops port liasons
C00649 00149 ∂15-Sep-86 1357 fateman@renoir.Berkeley.EDU ops-5
C00651 00150 ∂15-Sep-86 1438 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: OPS-5 in Common Lisp
C00654 00151 ∂15-Sep-86 1937 NGALL@G.BBN.COM defstruct slots' default-inits
C00656 00152 ∂17-Sep-86 1044 tsf@theory.cs.cmu.edu Readtables and prin1
C00658 00153 ∂17-Sep-86 1813 FAHLMAN@C.CS.CMU.EDU Readtables and prin1
C00660 00154 ∂17-Sep-86 1847 FAHLMAN@C.CS.CMU.EDU Readtables and prin1
C00662 00155 ∂17-Sep-86 2001 Moon@STONY-BROOK.SCRC.Symbolics.COM Readtables and prin1
C00666 00156 ∂17-Sep-86 2216 @DIAMOND.S4CC.Symbolics.COM:DDYER@RIVERSIDE.SCRC.Symbolics.COM Readtables and prin1
C00669 00157 ∂18-Sep-86 0701 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Re: Readtables and prin1
C00672 00158 ∂18-Sep-86 1037 FAHLMAN@C.CS.CMU.EDU Readtables and prin1
C00675 00159 ∂18-Sep-86 1039 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Re: OPS5 in Common Lisp
C00677 00160 ∂18-Sep-86 1100 LOOSEMORE@UTAH-20.ARPA *applyhook* question
C00678 00161 ∂18-Sep-86 1104 LOOSEMORE@UTAH-20.ARPA *applyhook* question (hopefully I'll get it right this time)
C00680 00162 ∂18-Sep-86 1538 pyramid!bein@hplabs.HP.COM testing addresses ... please ignore
C00681 00163 ∂19-Sep-86 1853 cross@afit-ab.ARPA please add my name
C00682 00164 ∂20-Sep-86 1751 cross@afit-ab.ARPA xlisp query
C00683 00165 ∂22-Sep-86 1734 @RIVERSIDE.SCRC.Symbolics.COM,@BIS-ALICE-LIDDELL.DialNet.Symbolics.COM:Stever@BIS-ALICE-LIDDELL.BISCC.DIALNET.SYMBOLICS.COM " macro character
C00685 00166 ∂22-Sep-86 1749 Moon@STONY-BROOK.SCRC.Symbolics.COM *applyhook* question (hopefully I'll get it right this time)
C00689 00167 ∂23-Sep-86 0352 ma←jpf%ux63.bath.ac.uk@Cs.Ucl.AC.UK OPS-5
C00690 00168 ∂24-Sep-86 1159 ACUFF@SUMEX-AIM.ARPA Re: Readtables and prin1
C00691 00169 ∂24-Sep-86 1932 FAHLMAN@C.CS.CMU.EDU Mailing list requests
C00692 00170 ∂24-Sep-86 1943 FAHLMAN@C.CS.CMU.EDU Readtables and prin1
C00694 00171 ∂25-Sep-86 0640 @MC.LCS.MIT.EDU:STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Are strings adjustable arrays?
C00696 00172 ∂25-Sep-86 1358 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Are strings adjustable arrays?
C00699 00173 ∂25-Sep-86 1416 RPG Jim Meehan Comments
C00702 00174 ∂26-Sep-86 0558 Dan@Think.COM Jim Meehan Comments
C00705 00175 ∂29-Sep-86 1037 DALY@IBM.COM getting on the common lisp list
C00706 00176 ∂03-Oct-86 1337 @MC.LCS.MIT.EDU:STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
C00708 00177 ∂03-Oct-86 1429 RAM@C.CS.CMU.EDU
C00710 00178 ∂03-Oct-86 1853 @REAGAN.AI.MIT.EDU:RDZ@AI.AI.MIT.EDU Printing DEFSTRUCTs
C00712 00179 ∂03-Oct-86 2100 DT50@A.CS.CMU.EDU printing structures
C00714 00180 ∂04-Oct-86 0023 bader@spice.cs.cmu.edu Re: printing structures
C00715 00181 ∂04-Oct-86 1817 RWK@YUKON.SCRC.Symbolics.COM Re: printing structures
C00718 00182 ∂05-Oct-86 2017 Masinter.pa@Xerox.COM Re: printing structures
C00721 00183 ∂05-Oct-86 2115 SOLEY@XX.LCS.MIT.EDU printing structures
C00723 00184 ∂05-Oct-86 2223 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Printing Structures
C00726 00185 ∂06-Oct-86 1045 DLW@ALDERAAN.SCRC.Symbolics.COM Printing Structures
C00729 00186 ∂06-Oct-86 2103 RWK@YUKON.SCRC.Symbolics.COM Re: printing structures
C00733 00187 ∂07-Oct-86 0917 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: printing structures
C00736 00188 ∂16-Oct-86 0123 KMP@STONY-BROOK.SCRC.Symbolics.COM DEFVAR
C00738 00189 ∂16-Oct-86 0123 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY
C00741 00190 ∂16-Oct-86 1604 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY
C00746 00191 ∂16-Oct-86 1801 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY
C00751 00192 ∂20-Oct-86 1046 FAHLMAN@C.CS.CMU.EDU DEFVAR
C00753 00193 ∂21-Oct-86 0851 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Applying functions to all the symbols in a package...
C00756 00194 ∂21-Oct-86 0913 FAHLMAN@C.CS.CMU.EDU Applying functions to all the symbols in a package...
C00759 00195 ∂30-Oct-86 1346 RPG Fahlman's remarks
C00768 00196 ∂30-Oct-86 1346 RPG Fahlman's remarks
C00771 00197 ∂30-Oct-86 1347 RPG Fahlman's remarks
C00773 00198 ∂30-Oct-86 1422 RPG Fahlman's remarks
C00780 00199 ∂31-Oct-86 1324 edsel!sunvalleymall!jlz@navajo.stanford.edu Call for Papers
C00787 00200 ∂31-Oct-86 1923 JAR@AI.AI.MIT.EDU [KLOTZ: defstruct initialization in :constructor ]
C00790 00201 ∂03-Nov-86 0718 samalone@ATHENA.MIT.EDU DEFSTRUCT copier query
C00792 00202 ∂03-Nov-86 0755 RAM@C.CS.CMU.EDU DEFSTRUCT copier query
C00794 00203 ∂03-Nov-86 1338 Pavel.pa@Xerox.COM Re: DEFSTRUCT copier query
C00797 00204 ∂03-Nov-86 1937 Bobrow.pa@Xerox.COM Re: DEFSTRUCT copier query
C00801 00205 ∂03-Nov-86 1938 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU DEFSTRUCT copier query
C00805 00206 ∂06-Nov-86 2120 sridhar%tekchips.tek.csnet@RELAY.CS.NET Why is #'equalp not allowed in make-hash-table ?
C00807 00207 ∂07-Nov-86 1028 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM DEFVAR
C00810 00208 ∂08-Nov-86 1208 RPG Re: from Japan
C00812 00209 ∂10-Nov-86 1921 Moon@STONY-BROOK.SCRC.Symbolics.COM Why is #'equalp not allowed in make-hash-table ?
C00815 00210 ∂11-Nov-86 1220 edsel!bhopal!jonl@navajo.stanford.edu Why is #'equalp not allowed in make-hash-table ?
C00820 00211 ∂11-Nov-86 1300 @MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA Why is #'equalp not allowed in make-hash-table ?
C00822 00212 ∂12-Nov-86 1435 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Declarations within FLET
C00823 00213 ∂14-Nov-86 0955 AI.BOYER@MCC.COM sloop
C00827 00214 ∂17-Nov-86 0218 z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET type-of
C00833 00215 ∂17-Nov-86 1503 RAM@C.CS.CMU.EDU type-of
C00836 00216 ∂18-Nov-86 0812 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU Package functions not powerful enough?
C00841 00217 ∂18-Nov-86 1058 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU [miller@UR-ACORN.ARPA: Package functions not powerful enough?]
C00847 00218 ∂18-Nov-86 1257 wile@vaxa.isi.edu Packages: a modest solution.
C00855 00219 ∂18-Nov-86 1304 RWK@YUKON.SCRC.Symbolics.COM type-of
C00870 00220 ∂18-Nov-86 1454 shebs%utah-orion@utah-cs.arpa Packages
C00873 00221 ∂18-Nov-86 1539 masinter.pa@Xerox.COM Re: type-of
C00876 00222 ∂18-Nov-86 1854 Miller.pa@Xerox.COM Re: Packages: a modest solution.
C00878 00223 ∂18-Nov-86 1906 RAM@C.CS.CMU.EDU Package functions not powerful enough?
C00881 00224 ∂18-Nov-86 1909 FAHLMAN@C.CS.CMU.EDU TYPE-OF
C00885 00225 ∂19-Nov-86 0749 shebs%utah-orion@utah-cs.arpa Re: type-of
C00887 00226 ∂19-Nov-86 0817 sandra%utah-orion@utah-cs.arpa type-of
C00891 00227 ∂19-Nov-86 1132 DLW@ALDERAAN.SCRC.Symbolics.COM Packages
C00895 00228 ∂19-Nov-86 2254 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Packages: a modest solution.
C00902 00229 ∂19-Nov-86 2355 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET TYPE-OF
C00913 00230 ∂20-Nov-86 0703 RAM@C.CS.CMU.EDU type-of
C00918 00231 ∂20-Nov-86 0747 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU fboundp question
C00919 00232 ∂20-Nov-86 1020 DLW@ALDERAAN.SCRC.Symbolics.COM side comment
C00921 00233 ∂20-Nov-86 1032 spe@cad.cs.cmu.edu EVAL
C00923 00234 ∂20-Nov-86 1150 DLW@VALLECITO.SCRC.Symbolics.COM TYPE-OF
C00927 00235 ∂20-Nov-86 1217 gls@think.com TYPE-OF
C00929 00236 ∂20-Nov-86 1250 RPG TYPE-OF
C00930 00237 ∂20-Nov-86 1325 FAHLMAN@C.CS.CMU.EDU EVAL
C00934 00238 ∂20-Nov-86 1433 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM TYPE-OF
C00938 00239 ∂20-Nov-86 1532 Pavel.pa@Xerox.COM Re: fboundp question
C00940 00240 ∂21-Nov-86 0242 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET question: EVAL
C00942 00241 ∂21-Nov-86 0613 RAM@C.CS.CMU.EDU question: EVAL
C00944 00242 ∂21-Nov-86 0637 RAM@C.CS.CMU.EDU TYPE-OF
C00948 00243 ∂21-Nov-86 0808 Moon@STONY-BROOK.SCRC.Symbolics.COM Packages
C00952 00244 ∂21-Nov-86 0944 wile@vaxa.isi.edu Package solution "motivation"
C00959 00245 ∂21-Nov-86 1152 RWK@STONY-BROOK.SCRC.Symbolics.COM type-of
C00966 00246 ∂21-Nov-86 1231 RWK@STONY-BROOK.SCRC.Symbolics.COM TYPE-OF
C00969 00247 ∂21-Nov-86 1300 RWK@STONY-BROOK.SCRC.Symbolics.COM TYPE-OF
C00976 00248 ∂21-Nov-86 1519 sandra%utah-orion@utah-cs.arpa Re: type-of
C00979 00249 ∂21-Nov-86 1657 RAM@C.CS.CMU.EDU TYPE-OF
C00984 00250 ∂22-Nov-86 1433 @REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU EVAL
C00987 00251 ∂22-Nov-86 1701 Pavel.pa@Xerox.COM Re: EVAL
C00989 00252 ∂22-Nov-86 1743 ricks%shambhala.Berkeley.EDU@BERKELEY.EDU Macrolet and setf
C00991 00253 ∂22-Nov-86 1820 @REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Re: EVAL
C00994 00254 ∂22-Nov-86 1922 Pavel.pa@Xerox.COM Re: Macrolet and setf
C00996 00255 ∂22-Nov-86 1932 franz!ficl!jkf@ucbarpa.Berkeley.EDU Re: Macrolet and setf
C00998 00256 ∂22-Nov-86 2052 FAHLMAN@C.CS.CMU.EDU Macrolet and setf
C01001 00257 ∂22-Nov-86 2054 RPG GET-SETF-METHOD
C01003 00258 ∂23-Nov-86 1236 RAM@C.CS.CMU.EDU (typep 3 'complex) => t
C01007 00259 ∂23-Nov-86 1413 Masinter.pa@Xerox.COM Re: (typep 3 'complex) => t
C01010 00260 ∂23-Nov-86 1432 RAM@C.CS.CMU.EDU (typep 3 'complex) => t
C01013 00261 ∂23-Nov-86 1538 Masinter.pa@Xerox.COM Re: (typep 3 'complex) => t
C01015 00262 ∂24-Nov-86 1135 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU question: EVAL
C01020 00263 ∂24-Nov-86 1300 sandra%utah-orion@utah-cs.arpa hash table question
C01022 00264 ∂24-Nov-86 1543 DLW@ALDERAAN.SCRC.Symbolics.COM hash table question
C01024 00265 ∂24-Nov-86 1630 sandra%utah-orion@utah-cs.arpa Re: hash table question
C01027 00266 ∂24-Nov-86 1725 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: hash table question
C01031 00267 ∂24-Nov-86 1959 FAHLMAN@C.CS.CMU.EDU hash table question
C01033 00268 ∂24-Nov-86 2130 edsel!bhopal!jonl@navajo.stanford.edu type-of
C01036 00269 ∂24-Nov-86 2134 edsel!bhopal!jonl@navajo.stanford.edu hash table question
C01043 00270 ∂25-Nov-86 2005 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU EVAL
C01047 00271 ∂25-Nov-86 2124 ALAN@AI.AI.MIT.EDU EVAL
C01049 00272 ∂26-Nov-86 0834 KMP@YUKON.SCRC.Symbolics.COM EVAL
C01057 00273 ∂26-Nov-86 0834 spe@cad.cs.cmu.edu Re: EVAL
C01059 00274 ∂26-Nov-86 1308 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU eval and other topics
C01066 00275 ∂26-Nov-86 1407 @WAIKATO.S4CC.Symbolics.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM eval and other topics
C01070 00276 ∂26-Nov-86 1734 ALAN@AI.AI.MIT.EDU EVAL
C01075 00277 ∂28-Nov-86 1341 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU EVAL
C01078 00278 ∂30-Nov-86 0026 ALAN@AI.AI.MIT.EDU EVAL
C01080 00279 ∂01-Dec-86 0954 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU eval and other topics
C01086 00280 ∂01-Dec-86 1239 spe@cad.cs.cmu.edu Packages
C01088 00281 ∂01-Dec-86 1326 @MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA Packages
C01091 00282 ∂01-Dec-86 1350 spe@cad.cs.cmu.edu Re: Packages
C01094 00283 ∂01-Dec-86 1434 @MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA Re: Packages
C01098 00284 ∂01-Dec-86 1847 DALY@IBM.COM progv and dynamic variables
C01099 00285 ∂01-Dec-86 1901 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU progv and dynamic variables
C01102 00286 ∂01-Dec-86 1945 DLW@ALDERAAN.SCRC.Symbolics.COM progv and dynamic variables
C01104 00287 ∂01-Dec-86 2227 franz!ficl!jkf@ucbarpa.Berkeley.EDU Re: progv and dynamic variables
C01106 00288 ∂01-Dec-86 2250 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU progv and dynamic variables
C01108 00289 ∂02-Dec-86 0928 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Packages
C01111 00290 ∂02-Dec-86 1844 jbarnett@nrtc Packages then and now
C01118 00291 ∂02-Dec-86 2113 Miller.pa@Xerox.COM Re: Packages then and now
C01120 00292 ∂02-Dec-86 2300 @REAGAN.AI.MIT.EDU:Henry@OZ.AI.MIT.EDU Common EVAL
C01142 00293 ∂03-Dec-86 2318 hplb29a!hplbgw!weeks@hplabs.HP.COM Re: Packages
C01148 00294 ∂05-Dec-86 1604 RMA ANSI doings?
C01149 00295 ∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU is it real or is it...
C01150 00296 ∂05-Dec-86 2055 shebs%utah-orion@utah-cs.arpa Underspecification of ~R
C01153 00297 ∂06-Dec-86 0758 MATHIS@ADA20.ISI.EDU ANSI doings
C01155 00298 ∂07-Dec-86 2249 ELIOT%cs.umass.edu@RELAY.CS.NET Added Keyword argument to load.
C01159 00299 ∂08-Dec-86 0531 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Underspecification of ~R
C01164 00300 ∂08-Dec-86 1256 @DIAMOND.S4CC.Symbolics.COM:chaowatkins@STONY-BROOK.SCRC.Symbolics.COM X3J13 mailing list
C01167 00301 ∂08-Dec-86 2233 RPG Re: testing suite
C01188 00302 ∂08-Dec-86 2237 RPG Common EVAL
C01210 00303 ∂08-Dec-86 2239 RPG SUBSET
C01214 00304 ∂08-Dec-86 2248 RPG from Japan
C01220 00305 ∂08-Dec-86 2249 RPG Lisp standardization
C01227 00306 ∂09-Dec-86 1605 RICHER@SUMEX-AIM.ARPA X window system
C01229 00307 ∂13-Dec-86 1653 RPG December minutes
C01255 00308 ∂14-Dec-86 1956 RPG activities at JEIDA
C01262 00309 ∂15-Dec-86 0456 RWK@YUKON.SCRC.Symbolics.COM FILE-WRITE-DATE, FILE-AUTHOR
C01267 00310 ∂15-Dec-86 1354 masinter.pa@Xerox.COM Re: FILE-WRITE-DATE, FILE-AUTHOR
C01271 00311 ∂16-Dec-86 1220 RWK@YUKON.SCRC.Symbolics.COM Re: FILE-WRITE-DATE, FILE-AUTHOR
C01276 00312 ∂18-Dec-86 1020 RPG Getting things rolling
C01283 00313 ∂18-Dec-86 1023 RPG Re: Getting things rolling
C01285 00314 ∂18-Dec-86 1328 RPG Re: Getting things rolling
C01289 00315 ∂18-Dec-86 1346 RPG Cleanup
C01292 00316 ∂18-Dec-86 1513 ELIOT%cs.umass.edu@RELAY.CS.NET File Operations
C01296 00317 ∂18-Dec-86 1625 Moon@STONY-BROOK.SCRC.Symbolics.COM File Operations
C01299 00318 ∂19-Dec-86 0924 @MIT-LIVE-OAK.ARPA,@PALLADIAN-JASPER.LCS.MIT.EDU,@WHITBY.Palladian.COM:dfm@PALLADIAN-JASPER.LCS.MIT.EDU sharp plus question
C01302 00319 ∂19-Dec-86 0957 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM sharp plus question
C01306 00320 ∂19-Dec-86 1222 KMP@STONY-BROOK.SCRC.Symbolics.COM FOLLOW-SYNONYM-STREAM
C01311 00321 ∂20-Dec-86 1216 RPG ISO Lisp WG meetings
C01315 00322 ∂21-Dec-86 1523 nelson%bach.DEC@decwrl.DEC.COM #+/-
C01317 00323 ∂22-Dec-86 0611 @DIAMOND.S4CC.Symbolics.COM:Greenwald@STONY-BROOK.SCRC.Symbolics.COM sharp plus question
C01324 00324 ∂22-Dec-86 1511 RPG Re: minutes of Dallas meeting
C01329 00325 ∂22-Dec-86 1552 robbins%ramona.DEC@decwrl.DEC.COM Re: FOLLOW-SYNONYM-STREAM
C01331 00326 ∂22-Dec-86 2035 RPG Getting things rolling
C01336 00327 ∂23-Dec-86 0927 RPG minutes of Dallas meeting
C01339 00328 ∂26-Dec-86 1521 RICHER@SUMEX-AIM.STANFORD.EDU CL-WINDOWS mailing list
C01341 00329 ∂29-Dec-86 1129 RICHER@SUMEX-AIM.STANFORD.EDU Re: CL-WINDOWS mailing list
C01343 00330 ∂30-Dec-86 1215 Masinter.pa@Xerox.COM courses on Common Lisp
C01345 00331 ∂02-Jan-87 2209 MURRAY%cs.umass.edu@RELAY.CS.NET Implicit Blocks considered harmful
C01348 00332 ∂03-Jan-87 1051 FAHLMAN@C.CS.CMU.EDU Implicit Blocks considered harmful
C01353 00333 ∂05-Jan-87 0736 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Implicit Blocks considered harmful
C01355 00334 ∂05-Jan-87 0759 williams%blue.decnet@ari-hq1.ARPA request list
C01356 00335 ∂05-Jan-87 0917 RPG Cleanup committee
C01359 00336 ∂06-Jan-87 0807 @ACORN.CS.ROCHESTER.EDU:miller@cs.rochester.edu maplist and lists
C01362 00337 ∂06-Jan-87 0840 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM maplist and lists
C01365 00338 ∂06-Jan-87 0959 @ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU maplist and lists
C01369 00339 ∂06-Jan-87 1005 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM maplist and lists
C01373 00340 ∂06-Jan-87 1238 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU maplist and lists
C01377 00341 ∂06-Jan-87 1555 tsf@theory.cs.cmu.edu Destructive operations
C01379 00342 ∂06-Jan-87 1629 FAHLMAN@C.CS.CMU.EDU Destructive operations
C01382 00343 ∂06-Jan-87 1738 edsel!babel!eb@navajo.stanford.edu Destructive operations
C01386 00344 ∂07-Jan-87 0802 jrg@spice.cs.cmu.edu mailin{ list requests
C01387 00345 ∂07-Jan-87 0840 tsf@theory.cs.cmu.edu Re: Destructive operations
C01389 00346 ∂07-Jan-87 1130 RPG A Happy New Year
C01392 00347 ∂07-Jan-87 1221 edsel!babel!eb@navajo.stanford.edu Destructive operations
C01395 00348 ∂09-Jan-87 0944 SAM@XX.LCS.MIT.EDU Recursive COMPILE-FILE?
C01397 00349 ∂09-Jan-87 0954 Moon@STONY-BROOK.SCRC.Symbolics.COM Recursive COMPILE-FILE?
C01400 00350 ∂09-Jan-87 1001 FAHLMAN@C.CS.CMU.EDU Recursive COMPILE-FILE?
C01403 00351 ∂09-Jan-87 1027 RPG Issues file
C01407 00352 ∂09-Jan-87 1234 SAM@XX.LCS.MIT.EDU Recursive COMPILE-FILE?
C01410 00353 ∂09-Jan-87 1747 RPG Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
C01415 00354 ∂09-Jan-87 2130 RPG Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
C01420 00355 ∂09-Jan-87 2130 RPG Issue: IMPORT-UNCLEAR, Message 1
C01423 00356 ∂10-Jan-87 0914 JAR@AI.AI.MIT.EDU Recursive COMPILE-FILE?
C01425 00357 ∂10-Jan-87 1123 RPG Mailing List
C01426 00358 ∂10-Jan-87 1246 FAHLMAN@C.CS.CMU.EDU Discussion strategy
C01430 00359 ∂10-Jan-87 1520 @MCC.COM:sierchio@mcc.com Bugs in Common LISPcraft
C01434 00360 ∂10-Jan-87 1633 masinter.pa@Xerox.COM Re: Discussion strategy
C01437 00361 ∂11-Jan-87 0004 CMP.LADAI@R20.UTEXAS.EDU Common Classes Bboard?
C01438 00362 ∂11-Jan-87 1136 RPG Issues file
C01442 00363 ∂11-Jan-87 1138 RPG Re: Issues file
C01446 00364 ∂11-Jan-87 1449 RWK@YUKON.SCRC.Symbolics.COM Recursive COMPILE-FILE?
C01449 00365 ∂11-Jan-87 1904 FAHLMAN@C.CS.CMU.EDU Format of proposals
C01452 00366 ∂11-Jan-87 1923 tsf@theory.cs.cmu.edu Packages & Compiling
C01456 00367 ∂11-Jan-87 1936 FAHLMAN@C.CS.CMU.EDU A comment on MACROLET...
C01460 00368 ∂11-Jan-87 1938 FAHLMAN@C.CS.CMU.EDU Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
C01461 00369 ∂11-Jan-87 1938 FAHLMAN@C.CS.CMU.EDU Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
C01462 00370 ∂11-Jan-87 1939 FAHLMAN@C.CS.CMU.EDU Issue: IMPORT-UNCLEAR, Message 1
C01463 00371 ∂11-Jan-87 2015 RAM@C.CS.CMU.EDU Packages & Compiling
C01468 00372 ∂11-Jan-87 2119 masinter.PA@Xerox.COM Re: Format of proposals
C01470 00373 ∂12-Jan-87 1048 tsf@theory.cs.cmu.edu Re: Packages & Compiling
C01474 00374 ∂12-Jan-87 1301 FAHLMAN@C.CS.CMU.EDU Mailing list
C01476 00375 ∂12-Jan-87 1403 DLW@ALDERAAN.SCRC.Symbolics.COM Packages & Compiling
C01480 00376 ∂12-Jan-87 1533 RAM@C.CS.CMU.EDU Packages & Compiling
C01484 00377 ∂12-Jan-87 1615 tsf@theory.cs.cmu.edu Re: Packages & Compiling
C01488 00378 ∂12-Jan-87 1640 KMP@STONY-BROOK.SCRC.Symbolics.COM mailing list requests
C01490 00379 ∂12-Jan-87 1711 RAM@C.CS.CMU.EDU Packages & Compiling
C01493 00380 ∂13-Jan-87 0534 RWK@YUKON.SCRC.Symbolics.COM Re: Packages & Compiling
C01497 00381 ∂13-Jan-87 0537 RWK@YUKON.SCRC.Symbolics.COM Packages & Compiling
C01503 00382 ∂13-Jan-87 2046 Moon@RIVERSIDE.SCRC.Symbolics.COM Format of proposals
C01507 00383 ∂13-Jan-87 2053 RAM@C.CS.CMU.EDU Packages & Compiling
C01510 00384 ∂14-Jan-87 0631 FAHLMAN@C.CS.CMU.EDU Mail problems
C01512 00385 ∂14-Jan-87 0633 FAHLMAN@C.CS.CMU.EDU [Fahlman: Issues file]
C01516 00386 ∂14-Jan-87 0634 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issues file]
C01520 00387 ∂14-Jan-87 0634 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1]
C01525 00388 ∂14-Jan-87 0635 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1]
C01531 00389 ∂14-Jan-87 0635 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issue: IMPORT-UNCLEAR, Message 1]
C01535 00390 ∂14-Jan-87 0645 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issue: IMPORT-UNCLEAR, Message 1]
C01539 00391 ∂14-Jan-87 0727 MATHIS@ADA20.ISI.EDU axolotl
C01540 00392 ∂14-Jan-87 1056 FAHLMAN@C.CS.CMU.EDU axolotl
C01542 00393 ∂14-Jan-87 1131 Margolin.VS3@BCO-MULTICS.ARPA &function
C01548 00394 ∂14-Jan-87 1232 RPG Batrachian reptile
C01549 00395 ∂14-Jan-87 1337 Moon@STONY-BROOK.SCRC.Symbolics.COM Lack of mail problems
C01550 00396 ∂14-Jan-87 1546 tsf@theory.cs.cmu.edu &function
C01554 00397 ∂14-Jan-87 1720 Masinter.pa@Xerox.COM Re: Batrachian reptile
C01555 00398 ∂14-Jan-87 1938 Masinter.pa@Xerox.COM Re: &function
C01557 00399 ∂15-Jan-87 0136 edsel!bhopal!jonl@navajo.stanford.edu Packages & Compiling
C01563 00400 ∂15-Jan-87 0606 @HI-MULTICS.ARPA:Margolin.Multics@HIS-PHOENIX-MULTICS.ARPA Re: &function
C01569 00401 ∂15-Jan-87 0821 RPG Issues of Function Cell
C01570 00402 ∂15-Jan-87 0827 gls@think.com Mail problems
C01572 00403 ∂15-Jan-87 1935 edsel!bhopal!jonl@navajo.stanford.edu Snakes and Lizards!
C01574 00404 ∂15-Jan-87 2043 hpfclp!dcm@hplabs.HP.COM axolotl
C01575 00405 ∂16-Jan-87 0643 vanroggen%bizet.DEC@decwrl.DEC.COM LISP POINTERS newsletter announcement
C01581 00406 ∂16-Jan-87 1432 primerd!doug@enx.prime.pdn
C01584 00407 ∂16-Jan-87 1607 wahlster@ernie.Berkeley.EDU mailing list
C01585 00408 ∂16-Jan-87 2059 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
C01589 00409 ∂16-Jan-87 2110 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: IMPORT-UNCLEAR, Message 1
C01593 00410 ∂16-Jan-87 2144 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
C01600 00411 ∂17-Jan-87 0954 DALY@IBM.COM :append keyword on compile-file
C01602 00412 ∂17-Jan-87 2117 hpfclp!diamant@hplabs.HP.COM Re: :append keyword on compile-file
C01605 00413 ∂17-Jan-87 2131 hpfclp!diamant@hplabs.HP.COM preprocessor-based Common Lisps
C01608 00414 ∂18-Jan-87 1156 DALY@IBM.COM append option on compile-file
C01610 00415 ∂18-Jan-87 1409 hpfclp!diamant@hplabs.HP.COM Re: preprocessor-based Common Lisps
C01614 00416 ∂18-Jan-87 1606 smh@mit-ems Re: preprocessor-based Common Lisps
C01616 00417 ∂19-Jan-87 0035 edsel!bhopal!jonl@navajo.stanford.edu :append keyword on compile-file
C01619 00418 ∂19-Jan-87 1218 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: preprocessor-based Common Lisps
C01621 00419 ∂19-Jan-87 1650 Masinter.pa@Xerox.COM discussion: macro environments
C01624 00420 ∂20-Jan-87 0331 @SAIL.STANFORD.EDU:REM@IMSSS Quoted structure not necessarily constant in my opinion, fix CLtL
C01633 00421 ∂20-Jan-87 1305 sandra%utah-orion@utah-cs.arpa *print-circle*
C01635 00422 ∂20-Jan-87 1451 vanroggen%bach.DEC@decwrl.DEC.COM Looking for Lisps...
C01639 00423 ∂21-Jan-87 0738 Pase.CCS@DOCKMASTER.ARPA Mailing List
C01640 00424 ∂21-Jan-87 1353 hpfclp!diamant@hplabs.HP.COM Re: preprocessor-based Common Lisps
C01643 00425 ∂21-Jan-87 1411 FAHLMAN@C.CS.CMU.EDU preprocessor-based Common Lisps
C01645 00426 ∂21-Jan-87 1915 Moon@STONY-BROOK.SCRC.Symbolics.COM *print-circle*
C01649 00427 ∂22-Jan-87 0553 GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU symbol-function of non-functions
C01652 00428 ∂22-Jan-87 0744 FAHLMAN@C.CS.CMU.EDU symbol-function of non-functions
C01654 00429 ∂22-Jan-87 0916 sandra%utah-orion@utah-cs.arpa Re: *print-circle*
C01658 00430 ∂22-Jan-87 1034 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: *print-circle*
C01662 00431 ∂22-Jan-87 1039 FAHLMAN@C.CS.CMU.EDU *print-circle*
C01664 00432 ∂22-Jan-87 1338 MURRAY%cs.umass.edu@RELAY.CS.NET *print-circle*
C01666 00433 ∂22-Jan-87 1416 Mailer@XX.LCS.MIT.EDU Re: symbol-function of non-functions
C01668 00434 ∂22-Jan-87 1527 Masinter.pa@Xerox.COM adjusting displaced arrays
C01670 00435 ∂22-Jan-87 1530 Moon@STONY-BROOK.SCRC.Symbolics.COM symbol-function of non-functions
C01674 00436 ∂22-Jan-87 1532 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Pushing defmacro hard: destructured &KEY bindings
C01677 00437 ∂22-Jan-87 1744 mincy@think.com Pushing defmacro hard: destructured &KEY bindings
C01680 00438 ∂22-Jan-87 2207 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU fsymeval before arg-eval?
C01682 00439 ∂23-Jan-87 0633 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: symbol-function of non-functions
C01685 00440 ∂23-Jan-87 0713 nelson%bach.DEC@decwrl.DEC.COM functionp/fboundp
C01689 00441 ∂23-Jan-87 0753 DLW@RIVERSIDE.SCRC.Symbolics.COM fsymeval before arg-eval?
C01691 00442 ∂23-Jan-87 0822 preece%mycroft@gswd-vms.ARPA functionp/fboundp
C01693 00443 ∂23-Jan-87 0906 preece%mycroft@gswd-vms.ARPA Re: functionp/fboundp
C01695 00444 ∂23-Jan-87 1125 sandra%utah-orion@utah-cs.arpa another question about defmacro lambda lists
C01697 00445 ∂23-Jan-87 1215 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM another question about defmacro lambda lists
C01700 00446 ∂23-Jan-87 1435 Moon@STONY-BROOK.SCRC.Symbolics.COM another question about defmacro lambda lists
C01702 00447 ∂23-Jan-87 1509 edsel!bhopal!jonl@navajo.stanford.edu fsymeval before arg-eval?
C01707 00448 ∂23-Jan-87 1604 REM@IMSSS symeval before or after args-eval?
C01709 00449 ∂24-Jan-87 1231 LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu Pattern matching in CL
C01711 00450 ∂24-Jan-87 1722 Mailer@XX.LCS.MIT.EDU another question about defmacro lambda lists
C01714 00451 ∂24-Jan-87 2344 Hvatum.DLAB@MIT-MULTICS.ARPA quoted structure
C01716 00452 ∂25-Jan-87 1742 Moon@RIVERSIDE.SCRC.Symbolics.COM another question about defmacro lambda lists
C01720 00453 ∂25-Jan-87 1743 Moon@RIVERSIDE.SCRC.Symbolics.COM fsymeval before arg-eval?
C01723 00454 ∂26-Jan-87 0755 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Are functions defined by FLET surrounded by an implicit BLOCK?
C01724 00455 ∂26-Jan-87 1407 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM another question about defmacro lambda lists
C01727 00456 ∂26-Jan-87 1413 Masinter.pa@Xerox.COM survey on Lisp courses
C01730 00457 ∂26-Jan-87 1456 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM another question about defmacro lambda lists
C01733 00458 ∂26-Jan-87 1456 Masinter.pa@Xerox.COM survey on Lisp courses
C01736 00459 ∂26-Jan-87 1605 Masinter.pa@Xerox.COM [PARCVAX.XEROX.COM, not PARC-VAX] and Re: symbol-function of
C01739 00460 ∂26-Jan-87 1853 Masinter.pa@Xerox.COM face-to-face meeting at X3
C01741 00461 ∂26-Jan-87 1944 FAHLMAN@C.CS.CMU.EDU face-to-face meeting at X3
C01745 00462 ∂26-Jan-87 2040 hpfclp!diamant@hplabs.HP.COM Re: preprocessor-based Common Lisps
C01750 00463 ∂27-Jan-87 0407 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM [PARCVAX.XEROX.COM, not PARC-VAX] and Re: symbol-function of
C01753 00464 ∂27-Jan-87 1119 Moon@RIVERSIDE.SCRC.Symbolics.COM Are functions defined by FLET surrounded by an implicit BLOCK?
C01755 00465 ∂27-Jan-87 1432 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by
C01759 00466 ∂27-Jan-87 2122 Moon@STONY-BROOK.SCRC.Symbolics.COM face-to-face meeting at X3
C01761 00467 ∂28-Jan-87 0646 MATHIS@ADA20.ISI.EDU Re: face-to-face meeting at X3
C01764 00468 ∂28-Jan-87 0713 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by
C01769 00469 ∂28-Jan-87 0803 FAHLMAN@C.CS.CMU.EDU [RAM: Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by]
C01772 00470 ∂28-Jan-87 1044 Dan@think.com survey on Lisp courses
C01774 00471 ∂28-Jan-87 1051 RPG the basic policy was decided in japan
C01778 00472 ∂28-Jan-87 1152 israel@brillig.umd.edu survey on Lisp courses
C01780 00473 ∂28-Jan-87 1659 TOURETZKY@C.CS.CMU.EDU extending sequence functions to arrays
C01784 00474 ∂28-Jan-87 1755 Masinter.pa@Xerox.COM Re: face-to-face meeting at X3
C01787 00475 ∂28-Jan-87 1754 Gregor.pa@Xerox.COM Re: survey on Lisp courses
C01788 00476 ∂29-Jan-87 1247 @DIAMOND.S4CC.Symbolics.COM:chaowatkins@STONY-BROOK.SCRC.Symbolics.COM please add me to common-lisp mailing list
C01790 00477 ∂29-Jan-87 1247 Mailer@XX.LCS.MIT.EDU Mentioning name twice in multiple-value-setq
C01792 00478 ∂29-Jan-87 1946 Pavel.pa@Xerox.COM MAKUNBOUND vs. special binding
C01796 00479 ∂29-Jan-87 2013 Moon@STONY-BROOK.SCRC.Symbolics.COM MAKUNBOUND vs. special binding
C01799 00480 ∂30-Jan-87 0712 FAHLMAN@C.CS.CMU.EDU Documents
C01801 00481 ∂30-Jan-87 0716 Hvatum.DLAB@MIT-MULTICS.ARPA &whole cum destructuring
C01806 00482 ∂30-Jan-87 0836 shebs%utah-orion@utah-cs.arpa Destructuring and &whole
C01809 00483 ∂30-Jan-87 0922 JAR@AI.AI.MIT.EDU MAKUNBOUND vs. special binding
C01812 00484 ∂30-Jan-87 1302 Moon@STONY-BROOK.SCRC.Symbolics.COM MAKUNBOUND vs. special binding
C01815 00485 ∂30-Jan-87 1308 Moon@STONY-BROOK.SCRC.Symbolics.COM Documents
C01817 00486 ∂30-Jan-87 1337 @MIT-LIVE-OAK.ARPA,@PALLADIAN-JASPER.LCS.MIT.EDU,@WHITBY.PALLADIAN.COM:dfm@PALLADIAN-JASPER.LCS.MIT.EDU *terminal-io* or *standard-output*?
C01819 00487 ∂31-Jan-87 1250 FAHLMAN@C.CS.CMU.EDU [SAFIER%cgi.csnet: proposed modification to common lisp]
C01822 00488 ∂01-Feb-87 1557 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Destructuring and &whole
C01826 00489 ∂02-Feb-87 0817 Masinter.pa@Xerox.COM Re: Documents
C01833 00490 ∂02-Feb-87 0935 Skef@think.com [SAFIER%cgi.csnet: proposed modification to common lisp]
C01837 00491 ∂02-Feb-87 1137 shebs%utah-orion@utah-cs.arpa Re: Parse as General Case of Read
C01839 00492 ∂02-Feb-87 1743 kempf%hplabsc@hplabs.HP.COM LALR Parser Generator Available?
C01841 00493 ∂02-Feb-87 1836 FAHLMAN@C.CS.CMU.EDU Just to clarify...
C01843 00494 ∂02-Feb-87 2300 edsel!bhopal!jonl@navajo.stanford.edu Rational Infinities
C01845 00495 ∂03-Feb-87 0044 TOURETZKY@C.CS.CMU.EDU Re: [Masinter.pa: Re: Documents]
C01847 00496 ∂03-Feb-87 0935 RPG From Japan
C01850 00497 ∂03-Feb-87 1230 wilensky%larch.Berkeley.EDU@BERKELEY.EDU Binding, etc.
C01861 00498 ∂03-Feb-87 1351 ELIOT%cs.umass.edu@RELAY.CS.NET Rational Infinity
C01863 00499 ∂03-Feb-87 1737 DLA@DIAMOND.S4CC.Symbolics.COM REMF and REMPROP
C01866 00500 ∂03-Feb-87 1912 jbarnett@NRTC.ARPA Re: Rational Infinity
C01871 00501 ∂04-Feb-87 0429 cugini@icst-ecf Binding terminology
C01874 00502 ∂04-Feb-87 0627 Cassels@STONY-BROOK.SCRC.Symbolics.COM Rational Infinity
C01879 00503 ∂04-Feb-87 0649 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Rational Infinity
C01882 00504 ∂04-Feb-87 0724 smh@EMS.MEDIA.MIT.EDU Re: LALR Parser Generator Available?
C01884 00505 ∂04-Feb-87 0831 FAHLMAN@C.CS.CMU.EDU REMF and REMPROP
C01888 00506 ∂04-Feb-87 1120 DALY@IBM.COM
C01890 00507 ∂04-Feb-87 1138 fateman@renoir.Berkeley.EDU Re: Rational Infinity
C01892 00508 ∂04-Feb-87 1250 FAHLMAN@C.CS.CMU.EDU REMF and REMPROP
C01895 00509 ∂04-Feb-87 1435 Moon@STONY-BROOK.SCRC.Symbolics.COM Binding terminology
C01898 00510 ∂04-Feb-87 1843 Miller.pa@Xerox.COM Re: Binding terminology
C01903 00511 ∂04-Feb-87 1916 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Binding terminology
C01905 00512 ∂04-Feb-87 2133 TOURETZKY@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
C01915 00513 ∂04-Feb-87 2139 RPG Re: Reports
C01918 00514 ∂05-Feb-87 0134 willc%tekchips.tek.com@RELAY.CS.NET Re: Binding, etc.
C01921 00515 ∂05-Feb-87 0819 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Common Lisp LOOP macro
C01922 00516 ∂05-Feb-87 0955 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Binding terminology
C01927 00517 ∂05-Feb-87 1008 DLA@DIAMOND.S4CC.Symbolics.COM REMF and REMPROP
C01932 00518 ∂05-Feb-87 1008 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM REMF and REMPROP
C01937 00519 ∂05-Feb-87 1008 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: Rational Infinity
C01940 00520 ∂05-Feb-87 1058 hplb29a!hplbgw!weeks@hplabs.HP.COM a historical inquiry
C01942 00521 ∂05-Feb-87 1108 FAHLMAN@C.CS.CMU.EDU REMF and REMPROP
C01946 00522 ∂05-Feb-87 1205 DLW@ALDERAAN.SCRC.Symbolics.COM a historical inquiry
C01949 00523 ∂05-Feb-87 1223 FAHLMAN@C.CS.CMU.EDU a historical inquiry
C01951 00524 ∂05-Feb-87 1237 Margolin.VS3@BCO-MULTICS.ARPA REMF and REMPROP
C01953 00525 ∂05-Feb-87 1420 gls@think.com a historical inquiry
C01955 00526 ∂05-Feb-87 1551 hoey@nrl-aic REMF and REMPROP
C01958 00527 ∂05-Feb-87 1633 hilfingr%tully.Berkeley.EDU@BERKELEY.EDU Re: Binding terminology
C01964 00528 ∂05-Feb-87 1700 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Binding terminology
C01967 00529 ∂05-Feb-87 1814 coffee@aerospace.aero.org Re: REMF and REMPROP
C01969 00530 ∂05-Feb-87 2154 @BCO-MULTICS.ARPA:Margolin.Multics@HIS-PHOENIX-MULTICS.ARPA Re: REMF and REMPROP
C01973 00531 ∂05-Feb-87 2241 edsel!bhopal!jonl@navajo.stanford.edu Rational Infinity
C01976 00532 ∂05-Feb-87 2308 edsel!bhopal!jonl@navajo.stanford.edu Re: Binding terminology
C01985 00533 ∂06-Feb-87 0659 DLA@DIAMOND.S4CC.Symbolics.COM REMF and REMPROP
C01990 00534 ∂06-Feb-87 0706 DLW@ALDERAAN.SCRC.Symbolics.COM REMF and REMPROP
C01996 00535 ∂06-Feb-87 0739 FAHLMAN@C.CS.CMU.EDU REMF and REMPROP
C02000 00536 ∂06-Feb-87 1041 DLW@ALDERAAN.SCRC.Symbolics.COM REMF and REMPROP
C02002 00537 ∂06-Feb-87 1240 Masinter.pa@Xerox.COM rational infinity
C02005 00538 ∂06-Feb-87 1359 coffee@aerospace.aero.org Re: REMF and REMPROP
C02008 00539 ∂06-Feb-87 1958 edsel!bhopal!jonl@navajo.stanford.edu Rational infinities
C02012 00540 ∂06-Feb-87 2006 FAHLMAN@C.CS.CMU.EDU Format for cleanup proposals
C02022 00541 ∂07-Feb-87 1952 JAR@AI.AI.MIT.EDU variables
C02025 00542 ∂07-Feb-87 2120 DALY@IBM.COM defstruct (resent due to lossage)
C02027 00543 ∂07-Feb-87 2205 RAM@C.CS.CMU.EDU defstruct (resent due to lossage)
C02029 00544 ∂08-Feb-87 1203 Masinter.pa@Xerox.COM Re: Format for cleanup proposals
C02035 00545 ∂08-Feb-87 1422 FAHLMAN@C.CS.CMU.EDU Format for cleanup proposals
C02038 00546 ∂09-Feb-87 0453 cugini@icst-ecf variable/binding terminology
C02041 00547 ∂09-Feb-87 0524 MATHIS@ADA20.ISI.EDU Re: Format for cleanup proposals
C02043 00548 ∂09-Feb-87 1104 hoey@nrl-aic Complex infinities
C02049 00549 ∂10-Feb-87 0800 Cassels@STONY-BROOK.SCRC.Symbolics.COM Rational Infinity
C02055 00550 ∂10-Feb-87 2141 edsel!bhopal!jonl@navajo.stanford.edu Rational Infinity
C02059 00551 ∂11-Feb-87 2032 DLA@DIAMOND.S4CC.Symbolics.COM Proposed Change to REMPROP and REMF
C02073 00552 ∂12-Feb-87 1423 shebs%utah-orion@utah-cs.arpa *APPLYHOOK* Vagueness
C02075 00553 ∂12-Feb-87 1631 SINGER@SPAR-20.ARPA Lexical globals
C02077 00554 ∂12-Feb-87 1656 FAHLMAN@C.CS.CMU.EDU Lexical globals
C02079 00555 ∂12-Feb-87 1714 Moon@STONY-BROOK.SCRC.Symbolics.COM *APPLYHOOK* Vagueness
C02082 00556 ∂13-Feb-87 1737 Masinter.pa@Xerox.COM Re: Proposed Change to REMPROP and REMF
C02089 00557 ∂16-Feb-87 1240 Masinter.pa@Xerox.COM Re: Format for cleanup proposals
C02092 00558 ∂16-Feb-87 1950 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Format for cleanup proposals
C02094 00559 ∂17-Feb-87 0653 MATHIS@ADA20.ISI.EDU Re: Format for cleanup proposals
C02095 00560 ∂17-Feb-87 1012 JAR@AI.AI.MIT.EDU Format for proposals to "clean up" Common Lisp
C02096 00561 ∂18-Feb-87 0949 RPG Lexical globals
C02103 00562 ∂19-Feb-87 1949 cugini@icst-ecf What does TYIPEEK mean?
C02107 00563 ∂22-Feb-87 1459 FAHLMAN@C.CS.CMU.EDU Compiler proposal
C02111 00564 ∂22-Feb-87 1501 FAHLMAN@C.CS.CMU.EDU Rob's Proposal
C02174 00565 ∂22-Feb-87 1854 FAHLMAN@C.CS.CMU.EDU Cleanup committee charter
C02183 00566 ∂23-Feb-87 1207 KMP@STONY-BROOK.SCRC.Symbolics.COM Cleanup committee charter
C02191 00567 ∂23-Feb-87 1243 FAHLMAN@C.CS.CMU.EDU Cleanup committee charter
C02194 00568 ∂23-Feb-87 1301 KMP@STONY-BROOK.SCRC.Symbolics.COM Cleanup committee charter
C02198 00569 ∂23-Feb-87 1323 FAHLMAN@C.CS.CMU.EDU Cleanup committee charter
C02201 00570 ∂23-Feb-87 1710 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C
C02208 00571 ∂23-Feb-87 1741 Moon@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C
C02210 00572 ∂23-Feb-87 1819 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C
C02212 00573 ∂23-Feb-87 1922 KMP@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER
C02218 00574 ∂23-Feb-87 1938 FAHLMAN@C.CS.CMU.EDU PRINC-CHARACTER
C02220 00575 ∂23-Feb-87 2207 edsel!gypsy-moth!kdo@navajo.stanford.edu (READ-CHAR T) vs. (FORMAT T)
C02222 00576 ∂24-Feb-87 0742 gls@Think.COM FORMAT-OP-C
C02223 00577 ∂24-Feb-87 0744 gls@Think.COM PRINC-CHARACTER
C02225 00578 ∂25-Feb-87 2007 Moon@STONY-BROOK.SCRC.Symbolics.COM Rob's Compiler Cleanup Proposal
C02235 00579 ∂25-Feb-87 2247 RPG [Andy Freeman <andy@shasta.stanford.edu>:]
C02241 00580 ∂26-Feb-87 0104 RAM@C.CS.CMU.EDU Rob's Compiler Cleanup Proposal
C02254 00581 ∂26-Feb-87 1504 RPG FUNCTION-TYPE
C02259 00582 ∂26-Feb-87 1944 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS
C02264 00583 ∂26-Feb-87 1945 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 2)
C02269 00584 ∂26-Feb-87 2004 KMP@STONY-BROOK.SCRC.Symbolics.COM DEFVAR-INITIALIZATION
C02273 00585 ∂27-Feb-87 0855 sandra%utah-orion@utah-cs.arpa What does this bit of code do?
C02275 00586 ∂27-Feb-87 0916 gls@Think.COM What does this bit of code do?
C02277 00587 ∂27-Feb-87 0934 gls@Think.COM FUNCTION-TYPE
C02279 00588 ∂27-Feb-87 1018 KMP@STONY-BROOK.SCRC.Symbolics.COM What does this bit of code do?
C02281 00589 ∂27-Feb-87 1423 KMP@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C02295 00590 ∂27-Feb-87 1518 KMP@YUKON.SCRC.Symbolics.COM COMPILER-WARNING-STREAM
C02299 00591 ∂27-Feb-87 1521 KMP@YUKON.SCRC.Symbolics.COM COMPILER-WARNING-BREAK
C02304 00592 ∂27-Feb-87 1557 KMP@YUKON.SCRC.Symbolics.COM IF-BODY
C02310 00593 ∂27-Feb-87 1607 KMP@YUKON.SCRC.Symbolics.COM FORMAT-ATSIGN-COLON
C02314 00594 ∂27-Feb-87 1651 KMP@YUKON.SCRC.Symbolics.COM SHARPSIGN-BACKSLASH-BITS
C02318 00595 ∂28-Feb-87 1835 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C02320 00596 ∂28-Feb-87 1841 FAHLMAN@C.CS.CMU.EDU IGNORE-ERRORS
C02322 00597 ∂28-Feb-87 1902 FAHLMAN@C.CS.CMU.EDU DEFVAR-INITIALIZATION
C02324 00598 ∂28-Feb-87 1910 RPG FUNCTION-TYPE
C02327 00599 ∂28-Feb-87 1930 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C02330 00600 ∂28-Feb-87 2050 FAHLMAN@C.CS.CMU.EDU UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C02333 00601 ∂28-Feb-87 2115 FAHLMAN@C.CS.CMU.EDU COMPILER-WARNING-STREAM
C02335 00602 ∂28-Feb-87 2120 FAHLMAN@C.CS.CMU.EDU [RAM: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT]
C02338 00603 ∂28-Feb-87 2153 FAHLMAN@C.CS.CMU.EDU IF-BODY
C02343 00604 ∂28-Feb-87 2158 FAHLMAN@C.CS.CMU.EDU FORMAT-ATSIGN-COLON
C02345 00605 ∂28-Feb-87 2207 FAHLMAN@C.CS.CMU.EDU SHARPSIGN-BACKSLASH-BITS
C02348 00606 ∂01-Mar-87 1649 RPG FUNCTION-TYPE
C02352 00607 ∂02-Mar-87 0718 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
C02361 00608 ∂02-Mar-87 0719 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-NUMBER
C02366 00609 ∂02-Mar-87 0924 sandra%utah-orion@utah-cs.arpa Re: What does this bit of code do?
C02368 00610 ∂02-Mar-87 0935 RAM@C.CS.CMU.EDU What does this bit of code do?
C02371 00611 ∂02-Mar-87 2127 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C02379 00612 ∂02-Mar-87 2133 Moon@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
C02382 00613 ∂02-Mar-87 2143 Moon@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-BACKSLASH-BITS
C02386 00614 ∂02-Mar-87 2149 Moon@STONY-BROOK.SCRC.Symbolics.COM IF-BODY
C02389 00615 ∂02-Mar-87 2157 Moon@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 2)
C02391 00616 ∂02-Mar-87 2302 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
C02393 00617 ∂03-Mar-87 0813 FAHLMAN@C.CS.CMU.EDU IF-BODY
C02396 00618 ∂03-Mar-87 0848 gls@Think.COM SHARPSIGN-PLUS-MINUS-PACKAGE
C02397 00619 ∂03-Mar-87 0917 gls@Think.COM SHARPSIGN-PLUS-MINUS-NUMBER
C02399 00620 ∂03-Mar-87 0957 gls@Think.COM FORMAT-ATSIGN-COLON
C02401 00621 ∂03-Mar-87 1000 gls@Think.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
C02403 00622 ∂03-Mar-87 1002 gls@Think.COM SHARPSIGN-BACKSLASH-BITS
C02404 00623 ∂03-Mar-87 1005 gls@Think.COM IF-BODY
C02406 00624 ∂03-Mar-87 1106 KMP@STONY-BROOK.SCRC.Symbolics.COM potential numbers
C02410 00625 ∂03-Mar-87 1151 gls@Think.COM SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD
C02412 00626 ∂03-Mar-87 1209 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY
C02416 00627 ∂03-Mar-87 1228 FAHLMAN@C.CS.CMU.EDU IF-BODY
C02419 00628 ∂03-Mar-87 1234 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
C02423 00629 ∂03-Mar-87 1250 KMP@STONY-BROOK.SCRC.Symbolics.COM (treatment of) IF-BODY
C02425 00630 ∂03-Mar-87 1710 Moon@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
C02428 00631 ∂03-Mar-87 1843 FAHLMAN@C.CS.CMU.EDU (treatment of) IF-BODY
C02430 00632 ∂03-Mar-87 2118 FAHLMAN@C.CS.CMU.EDU IF-BODY:NO
C02438 00633 ∂04-Mar-87 0654 gls@Think.COM IF-BODY
C02440 00634 ∂04-Mar-87 0934 edsel!bhopal!jonl@navajo.stanford.edu IMPORTations into keyword package
C02443 00635 ∂04-Mar-87 1601 RPG FUNCTION-TYPE
C02447 00636 ∂04-Mar-87 1924 MASINTER.PA@Xerox.COM meeting
C02448 00637 ∂04-Mar-87 2050 FAHLMAN@C.CS.CMU.EDU meeting
C02449 00638 ∂05-Mar-87 0657 gls@Think.COM FUNCTION-TYPE
C02452 00639 ∂05-Mar-87 1033 johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK evalhook, eval-when
C02457 00640 ∂05-Mar-87 1037 RPG FUNCTION-TYPE & Hermeneutics
C02459 00641 ∂05-Mar-87 1424 Moon@STONY-BROOK.SCRC.Symbolics.COM evalhook, eval-when
C02461 00642 ∂05-Mar-87 1513 Moon@STONY-BROOK.SCRC.Symbolics.COM evalhook, eval-when
C02463 00643 ∂05-Mar-87 2057 gls@Think.COM FUNCTION-TYPE & Hermeneutics
C02466 00644 ∂06-Mar-87 1026 RAM@C.CS.CMU.EDU evalhook, eval-when
C02472 00645 ∂06-Mar-87 1350 KMP@STONY-BROOK.SCRC.Symbolics.COM PEEK-CHAR-READ-CHAR-ECHO
C02491 00646 ∂07-Mar-87 0006 RWK@yukon.scrc.symbolics.com IMPORTations into keyword package
C02494 00647 ∂07-Mar-87 1452 RPG Rob's Compiler Proposal
C02498 00648 ∂07-Mar-87 1544 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: evalhook, eval-when
C02505 00649 ∂07-Mar-87 1559 RAM@C.CS.CMU.EDU Rob's Compiler Proposal
C02511 00650 ∂07-Mar-87 1614 RAM@C.CS.CMU.EDU evalhook, eval-when
C02514 00651 ∂07-Mar-87 1724 RPG Rob's Proposal etc
C02518 00652 ∂07-Mar-87 1733 Moon@STONY-BROOK.SCRC.Symbolics.COM eval-when [former subject evalhook, eval-when]
C02524 00653 ∂07-Mar-87 2004 RAM@C.CS.CMU.EDU FUNCTION type declaration
C02528 00654 ∂08-Mar-87 1206 RPG FUNCTION type declaration
C02531 00655 ∂08-Mar-87 1324 RPG FUNCTION Type Declaration
C02536 00656 ∂08-Mar-87 1424 vanMelle.pa@Xerox.COM Does *read-suppress* suppress list construction?
C02539 00657 ∂08-Mar-87 1428 FAHLMAN@C.CS.CMU.EDU PEEK-CHAR-READ-CHAR-ECHO
C02543 00658 ∂08-Mar-87 1448 FAHLMAN@C.CS.CMU.EDU SHARPSIGN-PLUS-MINUS-PACKAGE
C02545 00659 ∂08-Mar-87 1456 FAHLMAN@C.CS.CMU.EDU SHARPSIGN-PLUS-MINUS-NUMBER
C02547 00660 ∂08-Mar-87 1516 Moon@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
C02550 00661 ∂08-Mar-87 2153 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C02564 00662 ∂08-Mar-87 2351 RPG Scott's Remarks on FUNCTION Type
C02570 00663 ∂09-Mar-87 0802 FAHLMAN@C.CS.CMU.EDU Scott's Remarks on FUNCTION Type
C02576 00664 ∂09-Mar-87 0832 gls@Think.COM FUNCTION type declaration
C02581 00665 ∂09-Mar-87 1119 RPG Scott's Remarks and Other Important Matters
C02583 00666 ∂09-Mar-87 1138 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-NUMBER (revision 2)
C02592 00667 ∂09-Mar-87 1152 Masinter.pa@Xerox.COM Cleanup committee meeting at PARC, Sunday 2 PM
C02595 00668 ∂09-Mar-87 1204 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE (revision 2)
C02608 00669 ∂09-Mar-87 1342 KMP@STONY-BROOK.SCRC.Symbolics.COM PEEK-CHAR-READ-CHAR-ECHO
C02615 00670 ∂09-Mar-87 1511 Moon@STONY-BROOK.SCRC.Symbolics.COM Cleanup committee meeting at PARC, Sunday 2 PM
C02617 00671 ∂09-Mar-87 1941 RAM@C.CS.CMU.EDU PEEK-CHAR-READ-CHAR-ECHO
C02620 00672 ∂09-Mar-87 1942 FAHLMAN@C.CS.CMU.EDU PEEK-CHAR-READ-CHAR-ECHO
C02625 00673 ∂09-Mar-87 2017 RPG Sunday Meeting
C02626 00674 ∂09-Mar-87 2025 FAHLMAN@C.CS.CMU.EDU Scott's Remarks on FUNCTION Type
C02629 00675 ∂09-Mar-87 2309 RPG I sent a mail to cl-object-system
C02632 00676 ∂10-Mar-87 0748 KMP@STONY-BROOK.SCRC.Symbolics.COM PEEK-CHAR-READ-CHAR-ECHO
C02635 00677 ∂10-Mar-87 0748 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C02644 00678 ∂10-Mar-87 0938 RPG Function Type
C02645 00679 ∂10-Mar-87 1033 RPG SHARPSIGN-PLUS-MINUS-NUMBER
C02647 00680 ∂10-Mar-87 1221 AKBARI@CS.COLUMBIA.EDU please add me
C02649 00681 ∂10-Mar-87 1256 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C02653 00682 ∂10-Mar-87 1259 edsel!babel!lnz@navajo.stanford.edu [navajo!KMP@STONY-BROOK.SCRC.Symbolics.COM: PEEK-CHAR-READ-CHAR-ECHO]
C02657 00683 ∂10-Mar-87 1355 FAHLMAN@C.CS.CMU.EDU PEEK-CHAR-READ-CHAR-ECHO
C02660 00684 ∂10-Mar-87 1417 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C02665 00685 ∂10-Mar-87 1442 RPG Consistency is the Hob....
C02666 00686 ∂10-Mar-87 1512 gls@Think.COM PEEK-CHAR-READ-CHAR-ECHO: nostalgia
C02668 00687 ∂10-Mar-87 1602 yeung@cseb.usc.edu Mailing list
C02669 00688 ∂10-Mar-87 1626 Masinter.pa@Xerox.COM Re: Consistency is the Hob....
C02673 00689 ∂10-Mar-87 1637 Moon@STONY-BROOK.SCRC.Symbolics.COM PEEK-CHAR-READ-CHAR-ECHO
C02675 00690 ∂10-Mar-87 1717 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
C02678 00691 ∂10-Mar-87 1803 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
C02682 00692 ∂10-Mar-87 1811 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
C02684 00693 ∂10-Mar-87 2347 RPG Consistency
C02686 00694 ∂11-Mar-87 0928 FAHLMAN@C.CS.CMU.EDU #'anything
C02690 00695 ∂11-Mar-87 0930 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 3)
C02696 00696 ∂11-Mar-87 0931 RPG Consistency
C02703 00697 ∂11-Mar-87 0938 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 3)
C02709 00698 ∂11-Mar-87 1004 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 3)
C02715 00699 ∂11-Mar-87 1052 KMP@STONY-BROOK.SCRC.Symbolics.COM PROMPT-FOR
C02725 00700 ∂11-Mar-87 1341 Moon@YUKON.SCRC.Symbolics.COM PROMPT-FOR
C02729 00701 ∂11-Mar-87 1403 Moon@STONY-BROOK.SCRC.Symbolics.COM #'cond, etc.
C02734 00702 ∂11-Mar-87 1946 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
C02736 00703 ∂11-Mar-87 2010 FAHLMAN@C.CS.CMU.EDU PROMPT-FOR
C02738 00704 ∂11-Mar-87 2326 KMP@STONY-BROOK.SCRC.Symbolics.COM PROMPT-FOR
C02741 00705 ∂12-Mar-87 0924 Pavel.pa@Xerox.COM Re: PROMPT-FOR
C02745 00706 ∂12-Mar-87 1252 JAR@AI.AI.MIT.EDU #'cond, etc.
C02747 00707 ∂12-Mar-87 1405 Moon@STONY-BROOK.SCRC.Symbolics.COM #'cond, etc.
C02750 00708 ∂12-Mar-87 2010 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
C02753 00709 ∂13-Mar-87 1451 JAR@AI.AI.MIT.EDU #'cond, etc.
C02757 00710 ∂13-Mar-87 1724 Masinter.pa@Xerox.COM Issues
C02760 00711 ∂13-Mar-87 1728 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
C02765 00712 ∂13-Mar-87 1824 Masinter.pa@Xerox.COM Re: #'cond, etc.
C02767 00713 ∂13-Mar-87 1938 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
C02772 00714 ∂13-Mar-87 2121 KMP@STONY-BROOK.SCRC.Symbolics.COM #'cond, etc.
C02777 00715 ∂15-Mar-87 1631 masinter.pa@Xerox.COM the issues file currently -- take your pick
C02844 00716 ∂15-Mar-87 1638 masinter.pa@Xerox.COM additional topics
C02846 00717 ∂15-Mar-87 1848 masinter.pa@Xerox.COM released: compiler-warning-stream
C02850 00718 ∂15-Mar-87 1849 masinter.pa@Xerox.COM Issue format-atsign-colon
C02853 00719 ∂15-Mar-87 1850 masinter.pa@Xerox.COM Format for issues
C02859 00720 ∂15-Mar-87 1853 masinter.pa@Xerox.COM Issue IMPORT-SETF-SYMBOL-PACKAGE
C02862 00721 ∂15-Mar-87 1855 masinter.pa@Xerox.COM Issue FLET-IMPLICIT-BLOCK
C02871 00722 ∂15-Mar-87 1910 masinter.pa@Xerox.COM Issue COMPILER-WARNING-BREAK
C02876 00723 ∂15-Mar-87 1924 masinter.pa@Xerox.COM Report: meeting of cl-cleanup meeting
C02880 00724 ∂16-Mar-87 2023 JAR@AI.AI.MIT.EDU Global lexicals
C02882 00725 ∂17-Mar-87 2015 KVQJ@CSLI.Stanford.EDU please add me
C02883 00726 ∂20-Mar-87 1345 VERACSD@A.ISI.EDU Extension to MAP
C02885 00727 ∂20-Mar-87 1431 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue FLET-IMPLICIT-BLOCK
C02888 00728 ∂20-Mar-87 1431 Moon@STONY-BROOK.SCRC.Symbolics.COM Extension to MAP
C02890 00729 ∂20-Mar-87 1513 norvig%cogsci.Berkeley.EDU@Berkeley.EDU Re: Extension to MAP
C02893 00730 ∂20-Mar-87 1805 FAHLMAN@C.CS.CMU.EDU Issue FLET-IMPLICIT-BLOCK
C02896 00731 ∂20-Mar-87 2130 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue FLET-IMPLICIT-BLOCK
C02900 00732 ∂21-Mar-87 0147 RWK@YUKON.SCRC.Symbolics.COM Extension to MAP
C02903 00733 ∂21-Mar-87 1248 barmar@Think.COM Extension to MAP
C02905 00734 ∂21-Mar-87 1555 vrotney@venera.isi.edu Re: Extension to MAP
C02908 00735 ∂21-Mar-87 2117 kempf%hplabsc@hplabs.HP.COM CommonObjects on CommonLoops
C02912 00736 ∂22-Mar-87 0954 FAHLMAN@C.CS.CMU.EDU Issue FLET-IMPLICIT-BLOCK
C02916 00737 ∂22-Mar-87 0954 rda%epistemi.edinburgh.ac.uk@Cs.Ucl.AC.UK Request to be added to mailing list
C02918 00738 ∂22-Mar-87 2009 kempf%hplabsc@hplabs.HP.COM Re: CommonObjects on CommonLoops
C02921 00739 ∂23-Mar-87 0949 Masinter.pa@Xerox.COM Re: Issue FLET-IMPLICIT-BLOCK
C02923 00740 ∂23-Mar-87 1005 HASSETT%sp.unisys.com@RELAY.CS.NET Extension to MAP
C02927 00741 ∂23-Mar-87 1145 VERACSD@A.ISI.EDU Replies to Extension to MAP
C02930 00742 ∂23-Mar-87 2111 Pavel.pa@Xerox.COM (THE (VALUES ...) ...) with &KEY
C02934 00743 ∂24-Mar-87 1437 RAM@C.CS.CMU.EDU (THE (VALUES ...) ...) with &KEY
C02936 00744 ∂25-Mar-87 1256 gls@Think.COM Issue FLET-IMPLICIT-BLOCK
C02940 00745 ∂25-Mar-87 1321 gls@Think.COM Replies to Extension to MAP
C02942 00746 ∂25-Mar-87 1426 samalone@ATHENA.MIT.EDU Extension to MAP
C02944 00747 ∂25-Mar-87 1458 edsel!bhopal!jonl@navajo.stanford.edu Numerical Comparison: "required coercions"
C02948 00748 ∂25-Mar-87 1702 FAHLMAN@C.CS.CMU.EDU Replies to Extension to MAP
C02951 00749 ∂25-Mar-87 1931 fateman@mike.berkeley.edu Re: Numerical Comparison: "required coercions"
C02953 00750 ∂25-Mar-87 1937 VERACSD@A.ISI.EDU More on MAP
C02956 00751 ∂25-Mar-87 2030 FAHLMAN@C.CS.CMU.EDU More on MAP
C02959 00752 ∂25-Mar-87 2101 STEVER%OZ.AI.MIT.EDU@AI.AI.MIT.EDU Free variables in a LAMBDA which names a function
C02962 00753 ∂25-Mar-87 2124 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Free variables in a LAMBDA which names a function
C02964 00754 ∂25-Mar-87 2143 barmar@Think.COM Free variables in a LAMBDA which names a function
C02968 00755 ∂25-Mar-87 2201 Moon@STONY-BROOK.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
C02973 00756 ∂26-Mar-87 0259 RWK@YUKON.SCRC.Symbolics.COM Free variables in a LAMBDA which names a function
C02976 00757 ∂26-Mar-87 0301 RWK@YUKON.SCRC.Symbolics.COM Free variables in a LAMBDA which names a function
C02979 00758 ∂26-Mar-87 0648 gls@Think.COM Replies to Extension to MAP
C02982 00759 ∂26-Mar-87 0728 gls@Think.COM Numerical Comparison: "required coercions"
C02985 00760 ∂26-Mar-87 0806 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
C02989 00761 ∂26-Mar-87 1048 @DIAMOND.S4CC.Symbolics.COM:Greenwald@STONY-BROOK.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
C02997 00762 ∂26-Mar-87 1135 edsel!bhopal!jonl@navajo.stanford.edu Extension to MAP [if the shoe doesn't fit?]
C03000 00763 ∂26-Mar-87 1202 @DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
C03010 00764 ∂26-Mar-87 1137 edsel!bhopal!jonl@navajo.stanford.edu Free variables in a LAMBDA which names a function
C03015 00765 ∂26-Mar-87 1137 edsel!bhopal!jonl@navajo.stanford.edu Numerical Comparison: "required coercions"
C03019 00766 ∂26-Mar-87 1208 gls@Think.COM Re: Numerical Comparison: "required coercions"
C03022 00767 ∂26-Mar-87 1225 fateman@mike.Berkeley.EDU Re: Numerical Comparison: "required coercions"
C03025 00768 ∂26-Mar-87 1351 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Numerical Comparison: "required coercions"
C03028 00769 ∂26-Mar-87 1545 @DIAMOND.S4CC.Symbolics.COM:Greenwald@STONY-BROOK.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
C03033 00770 ∂26-Mar-87 1717 REM@IMSSS Coercion rule for comparisons
C03035 00771 ∂26-Mar-87 2139 VERACSD@A.ISI.EDU NMAP
C03040 00772 ∂27-Mar-87 0136 mcvax!lifia!phs@seismo.CSS.GOV Practical (values)
C03043 00773 ∂27-Mar-87 0740 FAHLMAN@C.CS.CMU.EDU Practical (values)
C03046 00774 ∂27-Mar-87 1312 VERACSD@A.ISI.EDU NMAP macro
C03049 00775 ∂27-Mar-87 2225 MURRAY%cs.umass.edu@RELAY.CS.NET NMAP a good idea.
C03055 00776 ∂27-Mar-87 2226 MURRAY%cs.umass.edu@RELAY.CS.NET NMAP a good idea if done correctly (blush)
C03062 00777 ∂28-Mar-87 0702 FAHLMAN@C.CS.CMU.EDU NMAP a good idea.
C03064 00778 ∂28-Mar-87 0828 frascado@umn-cs.arpa nmap
C03066 00779 ∂28-Mar-87 1202 pyramid!pyramid.UUCP!bein@hplabs.HP.COM Sequence functions ..
C03068 00780 ∂29-Mar-87 1345 sandra%utah-orion@utah-cs.arpa *terminal-io*
C03070 00781 ∂29-Mar-87 1415 smh@EMS.MEDIA.MIT.EDU Re: *terminal-io*
C03072 00782 ∂29-Mar-87 1625 sandra%utah-orion@utah-cs.arpa Re: *terminal-io*
C03074 00783 ∂29-Mar-87 2055 KMP@STONY-BROOK.SCRC.Symbolics.COM *terminal-io*
C03078 00784 ∂29-Mar-87 2210 MURRAY%cs.umass.edu@RELAY.CS.NET MAPing Sequences
C03081 00785 ∂30-Mar-87 0931 primerd!doug@enx.prime.pdn
C03083 00786 ∂30-Mar-87 1058 JAR@AI.AI.MIT.EDU almost scheme in common lisp
C03086 00787 ∂30-Mar-87 1144 Moon@STONY-BROOK.SCRC.Symbolics.COM Circular list implementation technique
C03088 00788 ∂30-Mar-87 1151 barmar@Think.COM *terminal-io*
C03091 00789 ∂30-Mar-87 1346 barmar@Think.COM MAPing Sequences
C03095 00790 ∂30-Mar-87 1428 EVAN@CSLI.Stanford.EDU NMAP
C03098 00791 ∂30-Mar-87 1533 primerd!doug@enx.prime.pdn Computed goto's
C03100 00792 ∂30-Mar-87 1602 DLA@DIAMOND.S4CC.Symbolics.COM Computed goto's
C03102 00793 ∂30-Mar-87 1638 wahlster@ernie.Berkeley.EDU Remove from Mailing List
C03103 00794 ∂30-Mar-87 1642 barmar@Think.COM Computed goto's
C03107 00795 ∂30-Mar-87 1820 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Computed goto's
C03112 00796 ∂30-Mar-87 2155 primerd!doug@enx.prime.pdn Computed goto's
C03114 00797 ∂30-Mar-87 2301 Moon@STONY-BROOK.SCRC.Symbolics.COM Discussion of computed GO and CASE
C03117 00798 ∂31-Mar-87 0635 DLA@DIAMOND.S4CC.Symbolics.COM Computed goto's
C03119 00799 ∂31-Mar-87 0830 shebs%utah-orion@utah-cs.arpa Computed goto's
C03121 00800 ∂31-Mar-87 0850 gls@Think.COM MAPing Sequences
C03123 00801 ∂31-Mar-87 1202 Masinter.pa@Xerox.COM "computed goto"
C03124 00802 ∂31-Mar-87 1338 primerd!doug@enx.prime.pdn Thanks for all the help
C03126 00803 ∂02-Apr-87 1943 Masinter.pa@Xerox.COM compiler-warning-stream
C03129 00804 ∂02-Apr-87 2235 ELIOT%cs.umass.edu@RELAY.CS.NET Clipping Output
C03131 00805 ∂06-Apr-87 1112 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Common Lisp symbols
C03133 00806 ∂06-Apr-87 1436 Moon@STONY-BROOK.SCRC.Symbolics.COM Common Lisp symbols
C03136 00807 ∂06-Apr-87 1638 primerd!doug@enx.prime.pdn Re: Common LISP Symbols
C03138 00808 ∂06-Apr-87 1918 DALY@IBM.COM all symbols
C03140 00809 ∂06-Apr-87 2236 MURRAY%cs.umass.edu@RELAY.CS.NET Clipping output
C03144 00810 ∂07-Apr-87 0003 masinter.PA@Xerox.COM time to reactivate cl-cleanup
C03147 00811 ∂07-Apr-87 0127 unido!gmdzi!jc@seismo.CSS.GOV Common Lisp symbols
C03150 00812 ∂07-Apr-87 0430 unido!gmdzi!jc@seismo.CSS.GOV Re: Common LISP Symbols
C03153 00813 ∂07-Apr-87 0431 unido!gmdzi!jc@seismo.CSS.GOV Common Lisp symbols
C03157 00814 ∂07-Apr-87 0658 @SAPSUCKER.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM all symbols
C03158 00815 ∂07-Apr-87 0919 FAHLMAN@C.CS.CMU.EDU time to reactivate cl-cleanup
C03161 00816 ∂07-Apr-87 0942 smh@EMS.MEDIA.MIT.EDU Re: all symbols
C03163 00817 ∂07-Apr-87 0953 @SAPSUCKER.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM Re: all symbols
C03165 00818 ∂07-Apr-87 1007 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU DEFVAR semantics
C03167 00819 ∂07-Apr-87 1506 Masinter.pa@Xerox.COM Re: time to reactivate cl-cleanup
C03174 00820 ∂07-Apr-87 1506 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT
C03188 00821 ∂07-Apr-87 1506 Masinter.pa@Xerox.COM Issue COMPILER-WARNING-BREAK (Revision 2)
C03193 00822 ∂07-Apr-87 1506 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Revision 3)
C03197 00823 ∂07-Apr-87 1525 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Revision 3)
C03201 00824 ∂07-Apr-87 1525 Masinter.pa@Xerox.COM Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
C03233 00825 ∂07-Apr-87 1627 nelson%bach.DEC@decwrl.DEC.COM Number of Common Lisp symbols
C03234 00826 ∂07-Apr-87 1741 Masinter.pa@Xerox.COM Issue: ENVIRONMENT-ARGUMENTS (Revision 1)
C03255 00827 ∂07-Apr-87 1753 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Revision 3)
C03264 00828 ∂07-Apr-87 2241 Hvatum.DLAB@MIT-MULTICS.ARPA NMAP innefficiency
C03267 00829 ∂07-Apr-87 2241 Hvatum.DLAB@MIT-MULTICS.ARPA Compiling CASE
C03270 00830 ∂08-Apr-87 0059 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Re: Common Lisp symbols
C03272 00831 ∂08-Apr-87 0723 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Compiling CASE
C03275 00832 ∂08-Apr-87 0808 smh@EMS.MEDIA.MIT.EDU all symbols
C03277 00833 ∂08-Apr-87 0844 las@bfly-vax.bbn.com "Compiling CASE"
C03282 00834 ∂08-Apr-87 1003 barmar@Think.COM Compiling CASE
C03285 00835 ∂08-Apr-87 1231 shebs%orion@cs.utah.edu Re: Compiling CASE
C03287 00836 ∂08-Apr-87 1403 primerd!doug@enx.prime.pdn Compiling CASE - back to the fray
C03289 00837 ∂08-Apr-87 1439 Mailer@XX.LCS.MIT.EDU Compiling CASE
C03294 00838 ∂08-Apr-87 1457 Masinter.pa@Xerox.COM Re: Compiling CASE
C03297 00839 ∂09-Apr-87 0222 Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: Compiling CASE
C03300 00840 ∂09-Apr-87 0535 Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU all symbols
C03303 00841 ∂09-Apr-87 0704 NGALL@G.BBN.COM Re: Compiling CASE
C03305 00842 ∂09-Apr-87 0707 gls@Think.COM Re: Compiling CASE
C03307 00843 ∂09-Apr-87 0719 RAM@C.CS.CMU.EDU Compiling CASE
C03310 00844 ∂09-Apr-87 0834 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM "Compiling CASE"
C03316 00845 ∂09-Apr-87 1117 sears%wrs.DEC@decwrl.DEC.COM Re-defining COMMON-LISP symbols
C03319 00846 ∂09-Apr-87 1154 FAHLMAN@C.CS.CMU.EDU Re-defining COMMON-LISP symbols
C03322 00847 ∂09-Apr-87 1310 gls@Think.COM Re-defining COMMON-LISP symbols
C03324 00848 ∂09-Apr-87 1413 RWK@YUKON.SCRC.Symbolics.COM DEFVAR semantics
C03326 00849 ∂10-Apr-87 0958 barmar@Think.COM Compiling CASE
C03328 00850 ∂11-Apr-87 0310 Hvatum.DLAB@MIT-MULTICS.ARPA Compiling CASE
C03335 00851 ∂11-Apr-87 0740 RAM@C.CS.CMU.EDU Compiling CASE
C03340 00852 ∂11-Apr-87 0810 RAM@C.CS.CMU.EDU Compiling CASE
C03343 00853 ∂11-Apr-87 1547 masinter.PA@Xerox.COM redefining Common Lisp functions
C03346 ENDMK
C⊗;
∂29-Jul-86 0328 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Re: exit-to-system
Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 03:28:11 PDT
Received: from utokyo-relay by csnet-relay.csnet id ac01013; 29 Jul 86 6:31 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA18879; Tue, 29 Jul 86 16:30:28+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA22657; Tue, 29 Jul 86 16:14:11+0900
Date: Tue, 29 Jul 86 16:14:11+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8607290714.AA22657@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, gls%aquinas.think.com@CSNET-RELAY.ARPA,
ida%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: Re: exit-to-system
Date: Mon, 21 Jul 86 15:01 EDT
From: Guy Steele <gls%ZARATHUSTRA.THINK.COM@u-tokyo.junet>
Subject: Re: exit-to-system
...
Well, we do have ED, which is clearly a user-interface thing.
Here is a stab at defining QUIT:
QUIT [Function]
This function is intended to terminate the running Lisp system in some
appropriate manner. ...
...
--Guy
I agree. The name QUIT sounds reasonable.
ida@utokyo-relay.csnet
-----
∂29-Jul-86 0623 Moon@RIVERSIDE.SCRC.Symbolics.COM Proposal #7: TYPE-SPECIFIER-P
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:23:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43549; Mon 28-Jul-86 20:24:25 EDT
Date: Mon, 28 Jul 86 20:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #7: TYPE-SPECIFIER-P
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
<860721-221520-2564@Xerox>,
<860722-102542-2911@Xerox>,
<860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
<860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<8607272237.AA21099@lmi-angel.ARPA>,
<FAHLMAN.12226129722.BABYL@C.CS.CMU.EDU>,
<FAHLMAN.12226153071.BABYL@C.CS.CMU.EDU>,
<860728111011.1.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<860728-123623-2787@Xerox>
Message-ID: <860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
TYPE-SPECIFIER-P is an appropriate name for a function that takes an
(OR SYMBOL LIST) and tells whether it's a valid specifier. If you're
going to replace this with a function that takes a SYMBOL and tells
whether it's the name of a type, call it TYPE-NAME-P.
However, I agree with Masinter's comment that we should concentrate on
fixing what is wrong with the language rather than adding more features.
I have no objection to either of TYPE-SPECIFIER-P or TYPE-NAME-P if
someone can show why these are needed to fix something wrong with the
language. Perhaps Guy can comment on why the original proposal 51 in
his clarifications list was tagged with an asterisk indicating that it
corrects an important flaw or resolves an ambiguity in the
specification.
∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Some easy ones (?)
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:41:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51598; Mon 28-Jul-86 17:32:55 EDT
Date: Mon, 28 Jul 86 17:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Some easy ones (?)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Message-ID: <860728173256.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I would find it much easier to follow these discussions if there
weren't ten discussions going on simultaneously in the -same-
messages. If each discussion was conducted in a different set
of messages, I could sort the messages into individual discussions
and read each discussion as an uninterrupted, coherent whole.
To practice what I preach, I am going to respond to each of the
ten proposals in your message of 21 July with a separate message
(except for the ones that I don't respond to at all).
∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #8: Clarifications to DEFCONSTANT
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51809; Mon 28-Jul-86 20:57:55 EDT
Date: Mon, 28 Jul 86 20:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #8: Clarifications to DEFCONSTANT
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
<860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
<FAHLMAN.12226153748.BABYL@C.CS.CMU.EDU>
Message-ID: <860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #8: Clarifications to DEFCONSTANT
Clarify that using DEFCONSTANT to redefine any constant described in the
Common Lisp specification is an error.
Non-controversial.
Clarify that if the user defines a constant, compiles code that refers
to that constant, and then redefines the constant, then behavior of the
compiled code may be unpredictable. It is an error to execute such
code.
Non-controversial, and "is an error" seems clearly the right level, rather
than "signals an error."
Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
[That last clarification has not been discussed previously, as far as I
know, but seems to be needed for reloading certain compiled code files,
etc.]
Do you mean EQL or EQUAL? Consider the example
(defconstant error-message-69 "Le *terminal-io* n'est pas une pipe.")
I don't see any good justification for reading and evaluating that form
twice to be an error. Consider that many Lisp dialects consider EQUAL
constants equivalent and coalesce them into EQ objects. Of course EQUAL
isn't exactly the right test either, since (equal #(1 2 3) #(1 2 3)) is nil.
The appropriate test would be one that compares all elements of structured
objects and compares atoms with EQL, which doesn't exist as a predefined
function in Common Lisp. Equality was one of the areas where we decided
to punt in the interests of getting a language specification out in a
finite time, since there wasn't complete agreement on what to do.
Perhaps parts 2 and 3 of this proposal properly belong to the system
environment, rather than to the programming language, especially when
you start talking about such concepts as "compiled code files".
∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #14: THE and VALUES
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51845; Mon 28-Jul-86 21:21:50 EDT
Date: Mon, 28 Jul 86 21:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #14: THE and VALUES
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
<860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
<RAM.12224974495.BABYL@C.CS.CMU.EDU>,
<860723125416.0.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<[G.BBN.COM]23-Jul-86 22:40:33.NGALL>,
<FAHLMAN.12226167693.BABYL@C.CS.CMU.EDU>
Message-ID: <860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Specify that in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and that any extra values are of unrestricted type.
Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).
I agree completely with MacLachlan's comments, enclosed. Both parts of
the proposal should be rejected. I do have one query; see below.
Plummer's suggestion of a standardized way to coerce a result to a
particular number of values sounds useful but should be raised as a
separate issue.
Date: Wed, 23 Jul 1986 09:50 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Well, I think everyone is wrong about this one. (THE (VALUES ...) ...)
specifies the functional type of the continuation. This is in effect
what CLTL already says: "...indicates the parameter list of a function
that, when given to multiple-value-call along with the values, would
be suitable for receiving those values."
My question is whether the quoted text (CLtL p.48) is a mistake. It could
have been accidentally retained from the days when multiple-value-bind
allowed & keywords, or it could be intentional.
I strongly disagree with any proposal which gives THE mandatory
run-time semantics. THE is a declaration --- its presence should not
change the meaning of a correct program. If the form returns too many
values, then the program is in error and the result is undefined.
I agree that it is highly desirable to be able to specify the
type of the first value without worrying about the actual number of
values. To this end, I propose that (THE FOO ...) should be
synonomous with the (THE (VALUES FOO &REST T) ...). This allows one
to say things like (THE FIXNUM (TRUNCATE ...)).
It should also be clarified that the VALUES type specifier may
have &ALLOW-OTHER-KEYS.
∂29-Jul-86 0642 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #11: Contents of Tagbody
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51834; Mon 28-Jul-86 21:07:53 EDT
Date: Mon, 28 Jul 86 21:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #11: Contents of Tagbody
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
<860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>,
<FAHLMAN.12226158847.BABYL@C.CS.CMU.EDU>
Message-ID: <860728210754.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #11: Contents of Tagbody
Specify that constant forms such as strings may appear at top-level in a
tagbody, but that only symbols and integers are considered to be tags.
It is an error to use anything else as the destination tag for a GO.
[Several forms of this have been kicked around. This seems as good as
any. The original issue was whether you could put something like a
string at top-level and, if so, whether you could go to it.]
I prefer Steele's original proposal, which was:
Specify explicitly that anything in a TAGBODY other than
a symbol, integer, or list is an error.
The manual already implies this, so the change would not be incompatible.
I can see nothing but user confusion resulting from allowing strings or
any other object that is not self-evidently either a form or a tag.
I'm more than willing to take (tagbody #1="bar" (print 1) (go #1#))
out of the Symbolics interpreter (the compiler already complains).
I think we should continue to allow integers as tags, for two reasons.
(1) Removing them would be an unnecessary incompatibility.
(2) Some people may be used to using integers as tags in other languages
(Basic, Pascal, Fortran) and these are the people most likely to be using
GO directly (rather than as part of the expansion of a macro).
∂29-Jul-86 0643 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #9: Variable Name Conflicts
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51857; Mon 28-Jul-86 22:10:57 EDT
Date: Mon, 28 Jul 86 22:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #9: Variable Name Conflicts
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
<860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>,
<12225052592.76.FREEMAN@SUMEX-AIM.ARPA>,
<[G.BBN.COM]23-Jul-86 21:39:54.NGALL>,
<[G.BBN.COM]23-Jul-86 23:55:15.NGALL>,
<12225270515.16.ANDY@Sushi.Stanford.EDU>,
<FAHLMAN.12225389688.BABYL@C.CS.CMU.EDU>,
The message of 25 Jul 86 00:30 EDT from Dave.Touretzky@A.CS.CMU.EDU,
<[G.BBN.COM]25-Jul-86 01:45:01.NGALL>,
The message of 25 Jul 86 09:15 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>,
<860725174559.4.GLS@IGNATIUS.THINK.COM>,
<12225647140.10.ANDY@Sushi.Stanford.EDU>,
<FAHLMAN.12225773488.BABYL@C.CS.CMU.EDU>,
<[G.BBN.COM]26-Jul-86 12:50:48.NGALL>,
<12225811022.11.ANDY@Sushi.Stanford.EDU>,
<FAHLMAN.12225827449.BABYL@C.CS.CMU.EDU>,
<860726-182347-1898@Xerox>,
<FAHLMAN.12225891798.BABYL@C.CS.CMU.EDU>,
<[AI.AI.MIT.EDU].76153.860726.ALAN>,
<FAHLMAN.12226156362.BABYL@C.CS.CMU.EDU>
Message-ID: <860728221058.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 22:02 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #9A:
It is an error for two parameters (including supplied-p and &aux
parameters) in the same lambda list to be represented by the same (EQ)
symbol. This also holds for parameters bound by LET, LET*, DO, DO*,
FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG.
There is no such thing as MV-BIND; I expect you meant MULTIPLE-VALUE-BIND.
You forgot PROG*. You omitted COMPILER-LET and PROGV, but I can't guess
whether this was accidental or intentional.
---------------------------------------------------------------------------
Proposal #9B:
Same, but don't include LET*.
---------------------------------------------------------------------------
Although I favor 9A, I have to point out that Fahlman has used his power
as moderator to make proposal 9B look bad. Surely the real 9B would
treat all of the sequential binding forms in a consistent way.
This appears to be one of those situations where the answer is obviously
correct, but the obviously correct answer is different for different
individuals. The only comment I can add is that no matter which
proposal is adopted, it is very easy for the proponents of the other
proposal to define a LET+ macro which is LET* done the way they wanted,
and similarly for the other sequential binding forms.
∂29-Jul-86 0643 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #13: Structure Sharing in Arguments
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:42:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51850; Mon 28-Jul-86 21:54:06 EDT
Date: Mon, 28 Jul 86 21:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #13: Structure Sharing in Arguments
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>,
<860722174822.6.DCP@FIREBIRD.SCRC.Symbolics.COM>,
The message of 23 Jul 86 00:39 EDT from hpfclp!diamant@hplabs.HP.COM,
<[G.BBN.COM]23-Jul-86 02:30:50.NGALL>,
<860723130828.1.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<860723132120.2.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<860723142439.9.MILLER@UR-CASHEW.ARPA>,
The message of 23 Jul 86 15:30 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>,
<8607232003.AA00325@tekchips.TEK>,
<860724141621.4.DCP@FIREBIRD.SCRC.Symbolics.COM>,
<FAHLMAN.12225382154.BABYL@C.CS.CMU.EDU>,
<FAHLMAN.12225383753.BABYL@C.CS.CMU.EDU>,
<8607251827.AA05634@utah-orion.ARPA>,
<860725150616.3.GLS@IGNATIUS.THINK.COM>,
<860726135509.3.DLW@CHICOPEE.SCRC.Symbolics.COM>,
<FAHLMAN.12225834449.BABYL@C.CS.CMU.EDU>,
<860726171228.4.DLW@CHICOPEE.SCRC.Symbolics.COM>,
<FAHLMAN.12225845128.BABYL@C.CS.CMU.EDU>,
The message of 26 Jul 86 18:38 EDT from SCOTT <SAFIER%cgi.csnet@CSNET-RELAY.ARPA>,
<8607262326.AA01397@utah-orion.ARPA>,
<FAHLMAN.12225931299.BABYL@C.CS.CMU.EDU>,
<FAHLMAN.12226167028.BABYL@C.CS.CMU.EDU>
Message-ID: <860728215406.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 86 15:06 EDT
From: Guy Steele <gls@Think.COM>
I think the lesson here is that, in general, you shouldn't ever clobber
a CONS if you don't know where it has been. Certain CL primitives do
guarantee to cons up fresh lists, and you can safely clobber their
results. Everything else you ought to be careful with, and that
includes &rest arguments, the results of PARSE-BODY, the results of FOO,
and so on. Unless a function or other construct is clearly documented
to indicate that it is okay to clobber its result, then you should avoid
doing so.
I agree so strongly with the above statement that I'm going to waste
hundreds of people's time by including it in my message so that they
have to read it again. The negation of this statement is practically
the definition of poor programming practice.
Date: Tue, 22 Jul 86 21:39:37 pdt
From: hpfclp!diamant@hplabs.HP.COM
....it better be clear that the
list returned may not be something which will go away on exiting the
function (which could happen if the parameter list were stored on the
stack and a pointer to that list was returned -- apparently what
Symbolics does).
Symbolics has always agreed that this aspect of our implementation is
not in conformance with Common Lisp, and have said so in our
documentation. We just haven't gotten around to fixing the bug yet, for
engineering reasons that I won't bore you by expounding. No one should
think that we oppose Diamant's statement above.
Date: Sun, 27 Jul 1986 23:01 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
13A: Specify that the &REST or &BODY argument to a macro may be the very
list from the macro call, and not a copy. Therefore, if this argument
is destructively modified, the originl text of the macro may also be
altered.
Agreed. Make sure the word is "might", not "must", where you now use
the ambiguous word "may" in two places.
Vanroggen brought up &WHOLE. The manual already implies that the &WHOLE
argument is required to be the original form, and not a copy, but this
should be made more explicit. Is this big enough to be a separate issue?
13B: Specify explicitly that the &REST argument in a function has
indefinite extent and may, for example, be returned to the function's
caller.
Agreed.
13C: The &REST list in a function is not necessarily a freshly-consed
list. If the function is called with APPLY, the &REST list may share
top-level structure with the last argument to the APPLY. Users should
keep this in mind if they are considering destructive modifications to
such a list.
Agreed, but the wording should be changed to say that an &REST argument
might share structure with something else regardless of how the function
was called, and simply use APPLY as an example. There is no reason to
put extra restrictions on the implementation here.
- OR -
13C': The &REST list in a function is freshly consed upon function entry.
It shares no top-level structure with any pre-existing list.
It's a bad idea to base the language specification on the idiosyncracies
of a particular implementation.
∂29-Jul-86 0644 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: Proposal about lambda-list params
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:43:26 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51852; Mon 28-Jul-86 21:58:19 EDT
Date: Mon, 28 Jul 86 21:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Proposal about lambda-list params
To: NGALL@G.BBN.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[G.BBN.COM]23-Jul-86 23:55:15.NGALL>
Message-ID: <860728215820.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 23 Jul 1986 23:55-EDT
From: NGALL@G.BBN.COM
The following thought just struck me. If we change CL to outlaw
things like (lambda (x x ...)...), then people who have been writing
code like (lambda (ignore x ignore) (declare (ignore ignore))...)
may be upset when their code breaks.
Since it "is an error", not "signals an error", those people are free to
criticize their compiler for wasting their time with worthless warnings
if it warns about this. It seems clear enough that warning about duplicate
parameter names when the parameters are explicitly ignored does no one
any good.
∂29-Jul-86 0649 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5 status
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:49:45 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25028; Tue 29-Jul-86 09:47:45 EDT
Date: Tue, 29 Jul 86 09:48 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5 status
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226431936.BABYL@C.CS.CMU.EDU>
Message-ID: <860729094823.0.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 28 Jul 1986 23:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
4. The macro-expansion for the first form in return value 3, if any.
Why the macroexpansion of the first form of the body? Why not the body
with the first form possibly expanded?
It saves a CONS.
As if macroexpansion doesn't cons up the wazoo?
It saves a CONS.
What's a CONS among friends?
It saves a CONS.
Let the GC take care of it.
It saves a CONS.
Since when does saving a single CONS dictate language design?
Why not toss in the kitchen sink? It looks to me like
design-by-committee disease is striking.
Why is it always the guy who endlessly nit-picks every last unimportant
detail who accuses others of design by committee?
If there isn't at least one nit-picking asshole (who unfortunately
doesn't read the 2 messages about etiquette burried in the middle of 30
messages before responding to half of the remaining 28), there is the
possibility that real issues won't be raised and that what some people
think are unimportant issues might turn out to be huge timebombs.
∂29-Jul-86 0652 NGALL@G.BBN.COM Re: Proposal about lambda-list params
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:52:40 PDT
Date: 29 Jul 1986 09:50-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Proposal about lambda-list params
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]29-Jul-86 09:50:57.NGALL>
In-Reply-To: <860728215820.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 28 Jul 86 21:58 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: 23 Jul 1986 23:55-EDT
From: NGALL@G.BBN.COM
The following thought just struck me. If we change CL to outlaw
things like (lambda (x x ...)...), then people who have been writing
code like (lambda (ignore x ignore) (declare (ignore ignore))...)
may be upset when their code breaks.
Since it "is an error", not "signals an error", those people are free to
criticize their compiler for wasting their time with worthless warnings
if it warns about this. It seems clear enough that warning about duplicate
parameter names when the parameters are explicitly ignored does no one
any good.
But under some of the new declaration-semantics proposals, the ignore
decl. would apply to only one of the parameters, thus given
(lambda (x y x z x) (declare (ignore x))...)
a compiler should still warn (or signal an error) that two of the
parameters illegally share a name. [Perhaps this can be used as an
argument against the proposal that a decl only affect only one of the
identically named entities to which it refers.]
-- Nick
∂29-Jul-86 0658 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5 status
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 06:56:42 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25036; Tue 29-Jul-86 09:54:51 EDT
Date: Tue, 29 Jul 86 09:55 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5 status
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226431936.BABYL@C.CS.CMU.EDU>
Message-ID: <860729095530.1.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 28 Jul 1986 23:16 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
As I pointed out in another message, the argument should be called
stop-parsing-on-string-p or something like that. I gave examples that
the current definition of parse-body implies are errors.
FYI, The normal way things appear in the manual is
{ declaration | doc-string }*
and that is also the order I have seen it (declarations before
doc-string) in code at Symbolics.
?? I assume somebody has convinced themselves that the ordering or
separation of declares has no semantic meaning in CL?
Yes, unless you have a counter-example.
I can't think of any, but I wanted to make sure somebody has convinced
themselves.
∂29-Jul-86 1123 DCP@QUABBIN.SCRC.Symbolics.COM Re: PARSE-BODY
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 10:23:59 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25110; Tue 29-Jul-86 11:54:38 EDT
Date: Tue, 29 Jul 86 11:55 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: PARSE-BODY
To: Masinter.pa@XEROX.COM, common-lisp@sail.stanford.edu
In-Reply-To: <860728-140217-2923@Xerox>
Message-ID: <860729115514.7.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: 28 Jul 86 13:43 PDT
From: Masinter.pa@Xerox.COM
a) it is of little general utility
Given the addition of &body variables for macros, I can think of no
examples where I would want to directly call parse-body instead of just
using the macro-expansion option. (I currently have lots of examples
that call parse-body, but they're all in macros that could use the new
&body options instead.)
(defmacro condition-bind (list &body body)
(expand-condition-bind ''t list body))
(defmacro conditin-bind-if (predicate list &body body)
(expand-condition-bind predicate list body))
Why should I be forced to destructure the body in the defmacro instead
of the common expansion routine?
∂29-Jul-86 1215 @SU-SCORE.ARPA,@REAGAN.AI.MIT.EDU:MLY@AI.AI.MIT.EDU Re: PARSE-BODY
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 10:25:29 PDT
Received: from REAGAN.AI.MIT.EDU by SU-SCORE.ARPA with TCP; Tue 29 Jul 86 08:52:15-PDT
Received: from RICKY.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 41068; Tue 29-Jul-86 11:55:55-EDT
Date: Tue, 29 Jul 86 11:54 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: Re: PARSE-BODY
To: Masinter.pa@Xerox.COM, common-lisp@sail.stanford.edu
In-Reply-To: <860728-140217-2923@Xerox>
Message-ID: <860729115443.3.MLY@RICKY.AI.MIT.EDU>
Date: 28 Jul 86 13:43 PDT
From: Masinter.pa@Xerox.COM
I am (now) opposed to adding PARSE-BODY to the Common Lisp standard (as
long as the parse-body option is added to the macro expansion argument
list) for the following reasons:
a) it is of little general utility
Given the addition of &body variables for macros, I can think of no
examples where I would want to directly call parse-body instead of just
using the macro-expansion option. (I currently have lots of examples
that call parse-body, but they're all in macros that could use the new
&body options instead.)
I disagree; here's an example, of which I could provide many more:
[I named it extract-declarations in some code I wrote to avoid a possible
conflict with anybody who had already implemented a function named PARSE-BODY]
(defmacro condition-case (form &rest clauses &environment environment)
"Execute FORM with conditions handled according to CLAUSES.
Each element of CLAUSES specifies one or more condition names,
and what to do if they are signalled.
More specifically, each clause is a list:
(<conditions> <arglist> . <body-forms...>)
<conditions> is not evaluated, and should be either a condition name
or a list of condition names to be handled.
<arglist> is either a list of a single symbol specifying a variable
to be bound to the condition being handled,
or () meaning that the clause is not interested in the particular
condition object.
<body-forms> are evaluated if a condition specified by <conditions>
is signalled. The value of the last of the forms is returned from
CONDITION-CASE in this case.
The clauses are considered in order, as in TYPECASE.
If no clause is executed to handle a condition, the values of FORM are returned."
#+lispm (declare (zwei:indentation 0 3 1 1))
(flet ((lose (&rest format)
(apply #'lisp:error "Error macro-expanding ~S: ~?"
'condition-case format)))
(dolist (clause clauses)
(cond ((not (consp clause))
(lose "clauses must be lists: ~S" clause))
((not (or (null (cadr clause))
(and (consp (cadr clause))
(null (cdr (cadr clause)))
(symbolp (car (cadr clause))))))
(lose "second element of a clause must be () or a list of a variable to bind: ~S"
clause))
;... other error checks...
))
(let ((gensym (gensym)))
`(block ,gensym
;; this depends on the order in which condition-bind and condition-case
;; clauses are defined to be searched
(condition-bind
;; I get a Gold Star for not using LOOP
(,@(mapcar #'(lambda (clause)
(multiple-value-bind (body decls)
(extract-declarations (cddr clause) environment)
`(,(car clause)
#'(lambda ,(or (cadr clause) (list gensym))
(declare
,@(if (cadr clause) () `((ignore ,gensym)))
,@decls)
#+symbolics
,@(if (cadr clause) () (list gensym))
(return-from ,gensym
(progn ,@body))))))
clauses))
,form)))))
If anything, I think that PARSE-BODY is more essential than the proposed
extensions to &BODY. (I am not overly fond of the &body-extensions
because of their dissimilarity to other defmacro destructuring, but
acknowledge their usefulness)
----------------------------------------------------------------------
b) it is controversial
While every implementation will have SOMETHING like parse-body (if only
to implement the handing of macro arguments) there seems to be little
agreement on what its arguments might be or what values it might return.
It would seem that every implementation wants something slightly
different (e.g., it depends on whether you cache macro translations as
for whether you want to save the macro translation & the work of
obtaining it or recompute it.)
The `controversy' I think you will find is over rather minor (even stupid)
details. (Like order arguments and returned values, and the stuff you
cite relating to Fahlman's 4th and 5th values)
I find your last argument (about macroexpansion efficiency) rather spurious.
----------------------------------------------------------------------
c) it isn't very simple
(This is isn't a simple argument to make, unfortunately.) The value of
features is inversly proportional to the complexity of their interfaces.
Functions that have a "process-it-this-way-p" arguments and "returns 3
values, but maybe just the first" should be viewed with suspicion, that
they don't represent the "true" interface to what is going on in the
system. That is, "parse-body" is just a piece of some more complex
processing of macros, arguments & bodies that is part of the language
writers toolkit, that isn't very isolated. Motivating it (what's this
for?) would be difficult without a lot more context.
Here's what I think is a pretty-much-adequate implementation (so much
for complexity!)
(defun extract-declarations (body &optional environment doc-string-valid-p)
"Extract declarations and documentation string from BODY and return them.
The first value is what is left of BODY after any doc string and decls are
removed. It is BODY missing some number of its initial elements.
The second value is the list of declarations found.
Each element of a DECLARE found in body is a declaration
and goes on this list.
The third value is the doc string found in BODY, if there was one.
However, doc strings are only processed if DOC-STRING-VALID-P is non-NIL."
#+lmnil (declare (values body declarations doc-string))
(let (form (doc nil) (decls ()))
(loop
;; Macro-expand the form, but don't worry if we get an error.
;; In that case, we will not see it as a declaration,
;; it will get macroexpanded again, and generate a warning then.
;;>> We can't use condition:condition-case since in this toy
;;>> implementation MACROEXPAND probably doesn't signal `our' errors
(setq form #+lmnil (si:condition-case ()
(macroexpand (car body) environment)
(si:error (return)))
#+lucid ;is buggy for (macroexpand '(declare)) [bugous?]
; Of course, this means we lose if DECLARE is
; lexically defined in ENVIRONMENT.
(if (and (consp (car body))
(eq (caar body) 'declare))
(car body)
;; this is about as good as I could figure
;; out without sources or a disassembler
(let ((tem (lucid::with-error-trapping
(macroexpand (car body)
environment))))
(if (and (consp tem)
(member (car tem)
'(lisp:error lisp:cerror))
(consp (cdr tem))
(string= (cadr tem) "Error")
(consp (cddr tem))
(stringp (caddr tem))
(consp (cdddr tem))
(listp (cadddr tem)))
form
tem)))
;; other implementations probably have some way to hack
;; ignore-errors
#-(or lmnil lucid)
(macroexpand (car body) environment)
)
(cond ((and doc-string-valid-p
(stringp form))
;; If the string is the last thing in the body,
;; don't inhale it, since it needs to be the return value.
(or (cdr body) (return))
;; We skip any number of strings, but use only the first.
(or doc (setq doc form)))
((and (consp form) (eq (car form) 'declare))
;; silently ignore badly-formed declare forms. Probably should warn.
(let ((decl (remove-if-not #'consp (the list (cdr form)))))
;; hack the DOCUMENTATION declaration specially
(let ((tem (assoc 'documentation decl)))
(when (and tem doc-string-valid-p)
(when (and (null doc)
(stringp (cadr tem)))
(setq doc (cadr tem)))
(setq decl (delete 'documentation decl :key #'car))))
(if decl
;; We allow any number of DECLAREs, and process them all.
(setq decls (append decl decls)))))
(t (return)))
(pop body))
(values body decls doc)))
∂29-Jul-86 1218 Miller.pa@Xerox.COM Re: Proposal about lambda-list params
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Jul 86 11:41:19 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 29 JUL 86 11:38:09 PDT
Date: 29 Jul 86 11:37 PDT
From: Miller.pa@Xerox.COM
Subject: Re: Proposal about lambda-list params
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Mon, 28 Jul 86 21:58 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA
Message-ID: <860729-113809-3801@Xerox>
Date: Mon, 28 Jul 86 21:58 EDT
From: David A. Moon
Date: 23 Jul 1986 23:55-EDT
From: NGALL@G.BBN.COM
The following thought just struck me. If we change CL to outlaw
things like (lambda (x x ...)...), then people who have been
writing
code like (lambda (ignore x ignore) (declare (ignore ignore))...)
may be upset when their code breaks.
Since it "is an error", not "signals an error", those people are free
to
criticize their compiler for wasting their time with worthless warnings
if it warns about this. It seems clear enough that warning about
duplicate
parameter names when the parameters are explicitly ignored does no one
any good.
"it is an error" means that a correct compiler may generate arbitrary
and worthless code when it encounters this case. If "(lambda (ignore x
ignore) (declare (ignore ignore))...)" is an error, then it may do worse
than break. This should either be legal, specified to signal an error,
or at least specified that, if not caught, will be harmless (not one of
the error catagories I know of)
∂29-Jul-86 1219 DCP@QUABBIN.SCRC.Symbolics.COM Staus of proposals 10, 11, and 12
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 10:34:11 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25108; Tue 29-Jul-86 11:49:59 EDT
Date: Tue, 29 Jul 86 11:50 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Staus of proposals 10, 11, and 12
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226438578.BABYL@C.CS.CMU.EDU>
Message-ID: <860729115038.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Mon, 28 Jul 1986 23:53 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #10: Forms That Allow Declarations
I did question the need/usefullness of allowing declarations in
MACROLET. Nobody has responded and I still can't think of any.
It would come as a nasty surprise to people if MACROLET were different
from FLET and LABELS in this respect.
I'm not saying we shouldn't do it, I'm saying we should acknowledge we
don't know what to do with it yet. There have been parts of the
Symbolics documentation that say "We think this is useful but haven't
figured out for what yet. We encourage experimentation and reports of
its usage." I may have thought of one usage:
(macrolet ((print-them (list)
`(mapc #'print ,list)))
(declare (notinline mapc))
...)
If anybody else believes this, perhaps it should be one of the examples?
∂29-Jul-86 1220 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA Re: Proposal #7 Status: TYPE-SPECIFIER-P
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 10:34:24 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 5930; 29 Jul 86 12:57:53-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 31206; Tue 29-Jul-86 12:50:36-EDT
Date: Tue, 29 Jul 86 12:47 EST
Sender: mike%gold-hill-acorn@mit-live-oak.arpa
To: Masinter.pa@Xerox.COM
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: Re: Proposal #7 Status: TYPE-SPECIFIER-P
cc: common-lisp@su-ai.arpa
Date: 28 Jul 86 1301 PDT
......
From:
Subject: Re: Proposal #7 Status: TYPE-SPECIFIER-P
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
27 Jul 86 21:44 EDT
......
On some further thought, TYPE-SPECIFIER-P is ambiguous in some cases
where the argument is a symbol:
Suppose you have
(deftype relatively-prime-to (n) `(satisfies (lambda (x) (= 1 (gcd x
,n)))))
In this case, relatively-prime-to by itself is not "a valid type
specifier".
(relatively-prime-to 10) is a valid type specifier, and
(relatively-prime-to t) is not.
Your point about deftype can be looked at differently.
If I have a deftype, i.e., (deftype mod (n) ...) etc. then
"mod" is a parameterized type.
The polymorphic lambda calculus has abstraction and
beta reduction defined for types, so following its example, the
type of "mod" might be (type-lambda (n) <type-expression in n>), where
type-lambda is the type abstraction.
In the light of this, (type-specifier-p 'relatively-prime-to) should
be true (independent of whether we add any type-abstraction notations to CL).
{ aside:: By the way, the polymorphic lambda calculus is fairly
interesting, so for those of you interested in fixing up the type
system, I suggest you look at it carefully. If you want, send me
mail (NO NOT TO THE CL MAILING LIST!!) and I will send some
references. :-) }
Any attempt to make type-specifier-p tell you whether a type specifier
specifies any real class of objects cannot work due to undecidability
problems. What we want is a SYNTACTIC property.
Is the intent "is this something I can hand to typep?" If so, it would
be false for "relatively-prime-to". If the intent is "does this *name* a
type-specifier" then we could allow it, but the usefulness of such a
thing is unclear to me.
Note that (typep 'relatively-prime-to...) should be invalid, since
'relatively-prime-to is not a type, but it IS a valid specifier.
Note, there are no objects of type (type-lambda (n) ...) since those
objects would be TYPES, not instances of types.
.....
d) of all of the proposals to consider, proposals to add new constructs
should get much lower priority than those to clarify or standardize
current constructs.
Amen.
I just think we should plan to revise the type system somewhat, instead of
just adding features. I agree that this is fairly low priority, and in
the light of...
e) there is another proposal (before the Object Oriented Programming
committee in this case) which satisfies at least part of the original
requirement in a different way.
Most object-oriented stuff impacts the type system dramatically, so
we should reexamine the type-system in light of object oriented extentions.
...mike beckerle
Gold Hill Computers
∂29-Jul-86 1255 RPG Yapper of the Month Club
To: common-lisp@SAIL.STANFORD.EDU
From May 14 through July 28 there were 690 messages to
Common-Lisp, around 9 a day. Here are the top message senders
with the number of messages sent during that period. There is
a fairly sharp break between these folks and the rest, with several
having 10 messages or so.
132 Fahlman
56 Plummer
44 Gall
30 Masinter
27 Steele
25 Moon
24 Weinreb
23 Pitman
20 Loosemore
18 Foderaro
18 Beckerle (Mike@a)
18 Shebs
Er, congratulations.
-rpg-
∂29-Jul-86 1456 FAHLMAN@C.CS.CMU.EDU Proposed moratorium (clarification)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 14:56:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 29 Jul 86 17:56:41-EDT
Date: Tue, 29 Jul 1986 17:56 EDT
Message-ID: <FAHLMAN.12226635848.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposed moratorium (clarification)
At the end of my suggestion for a Lisp Conference moratorium on
technical mail, I said "this is only a suggestion, but I can't guarantee
that mail arriving during that itme will be read." This was a feeble
attempt at a joke. All mail will be read eventually. I still think it
would be a good idea to ease up on the mail during this period, however.
Sometimes I get comedy and tragedy confused, I'm afraid.
-- Scott
∂29-Jul-86 1734 pyramid!bein@SUN.COM closing standard channels
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 29 Jul 86 17:34:24 PDT
Received: from sun.uucp by sun.com (3.2/SMI-3.0)
id AA14484; Tue, 29 Jul 86 17:34:11 PDT
Received: by sun.uucp (1.1/SMI-3.0)
id AA12057; Tue, 29 Jul 86 17:34:55 PDT
Received: by pyramid (4.12/3.14)
id AA02084; Tue, 29 Jul 86 17:10:26 pdt
Date: 29 Jul 1986 17:07-PDT
From: David Bein <pyramid!bein@SUN.COM>
Subject: closing standard channels
To: common-lisp@su-ai.ARPA
Message-Id: <523066026/bein@pyramid>
I know this question may have been asked before..
What seems to be the consensus on closing streams
like *terminal-io*,*standard-input*, etc? Should it
be an error to try to close them, should it be a
noop or what?
--David
∂29-Jul-86 1835 NGALL@G.BBN.COM Re: Proposal #9: Variable Name Conflicts
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 18:35:08 PDT
Date: 29 Jul 1986 21:33-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Proposal #9: Variable Name Conflicts
From: NGALL@G.BBN.COM
To: Moon@SCRC-STONY-BROOK.ARPA
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]29-Jul-86 21:33:23.NGALL>
In-Reply-To: <860728221058.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 28 Jul 86 22:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 22:02 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #9A:
It is an error for two parameters (including supplied-p and &aux
parameters) in the same lambda list to be represented by the same (EQ)
symbol. This also holds for parameters bound by LET, LET*, DO, DO*,
FLET, LABELS, PROGV, MACROLET, MV-BIND, and PROG.
There is no such thing as MV-BIND; I expect you meant MULTIPLE-VALUE-BIND.
You forgot PROG*. You omitted COMPILER-LET and PROGV, but I can't guess
whether this was accidental or intentional.
I think I submitted this list of var. binding forms. I abbreviated
MULTIPLE-VALUE to MV, sorry if it wasn't clear. PROGV wasn't omitted
(see?). The omission of compiler-let and prog* was accidental
(compiler-let wasn't in the list on page 154 (which was all I looked
at) and I guess I didn't see prog* under prog).
-- Nick
∂29-Jul-86 1848 NGALL@G.BBN.COM Re: Staus of proposals 10, 11, and 12
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jul 86 18:47:54 PDT
Date: 29 Jul 1986 21:47-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Staus of proposals 10, 11, and 12
From: NGALL@G.BBN.COM
To: Common-Lisp@SU-AI.ARPA
Cc: Fahlman@C.CS.CMU.EDU
Message-ID: <[G.BBN.COM]29-Jul-86 21:47:02.NGALL>
In-Reply-To: <860729115038.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Date: Tue, 29 Jul 86 11:50 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
I may have thought of one usage:
(macrolet ((print-them (list)
`(mapc #'print ,list)))
(declare (notinline mapc))
...)
If anybody else believes this, perhaps it should be one of the examples?
I don't believe it. The stuff inside the backquoted list is not code,
it is data. Here's a similar one that I believe:
(macrolet ((print-them (list)
`(progn ,@(mapcar #'(lambda (item) `(print ',item))
list)))
(declare (notinline mapcar))
...)
In this, the mapcar funcall form IS code. Note that this still is not
a strong argument for decls in the body of a macrolet, since the decl
could have been put in the body of the print-them macro definition.
But I agree that we should allow decls in the body of a macrolet.
-- Nick
∂29-Jul-86 1854 FAHLMAN@C.CS.CMU.EDU Proposal #8: Clarifications to DEFCONSTANT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 18:54:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 29 Jul 86 21:53:34-EDT
Date: Tue, 29 Jul 1986 21:53 EDT
Message-ID: <FAHLMAN.12226678969.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #8: Clarifications to DEFCONSTANT
In-reply-to: Msg of 28 Jul 1986 20:57-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
Do you mean EQL or EQUAL? Consider the example
(defconstant error-message-69 "Le *terminal-io* n'est pas une pipe.")
I don't see any good justification for reading and evaluating that form
twice to be an error.
Well, we prohibit compilers from replacing a constant reference with
inline code that is merely EQUAL to the constant; it must be EQL. This
was so that you could do things like
(defconstant terminator '(nil))
and then do EQL testing for instances of TERMINATOR. Perhaps this is
bogus, but if we keep that, we can't allow users to redefine constants
to other values that are merely EQUAL, because it will break such code.
I am not sure if it is safe to detect that the new constant value is
EQUAL to the old one and, if so, to leave the old one in place.
-- Scott
∂29-Jul-86 1920 FAHLMAN@C.CS.CMU.EDU Proposal #9: Variable Name Conflicts
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 86 19:20:05 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 29 Jul 86 22:20:14-EDT
Date: Tue, 29 Jul 1986 22:20 EDT
Message-ID: <FAHLMAN.12226683825.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #9: Variable Name Conflicts
Although I favor 9A, I have to point out that Fahlman has used his power
as moderator to make proposal 9B look bad. Surely the real 9B would
treat all of the sequential binding forms in a consistent way.
If I were to propose something along these lines, it would be to treat
all of the sequential binding forms (including LAMBDA/DEFUN) in a
consistent way. I believe that Andy Freeman was the one who first
argued for what became 9B, and he specifically said that LAMBDA/DEFUN
should not allow multiple args of the same name. He couldn't decide
about DO*.
If, in summarizing, I replace the opposition's proposals with something
I think is better, that's an abuse of power. If I faithfully report
what was proposed when I know better, I'm making them look bad,
and that's also an abuse of power. Oh, well.
-- Scott
∂30-Jul-86 0640 MASINTER.PA@Xerox.COM declarations in macrolet puzzle
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 06:40:49 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 30 JUL 86 06:41:09 PDT
From: MASINTER.PA@Xerox.COM
Date: 30 Jul 86 6:40:17 PDT
Subject: declarations in macrolet puzzle
To: common-lisp@su-ai.ARPA
Message-ID: <860730-064109-1194@Xerox>
(macrolet ((specials () (specials) '(declare (special special-list ,@special-list))))
(specials)
special-list))
since macros can expand into declarations
and bodies have to have macros expanded before declarations can be seen
yet macrolet macros are visible in the body then ...
∂30-Jul-86 0705 RAM@C.CS.CMU.EDU Declarations in MACROLET
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 07:05:34 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Wed 30 Jul 86 10:06:00-EDT
Date: Wed, 30 Jul 1986 10:05 EDT
Message-ID: <RAM.12226812298.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Declarations in MACROLET
I don't think that it would be correct for a declaration at the
head of a macrolet to affect the bodies of any of the macros, since
the bodies of the macros are defined to be in the null environment.
The only use for declarations in this place would be to make pervasive
declarations which affect the body of the MACROLET. Of course this
could be done by LOCALLY.
Rob
∂30-Jul-86 1001 gls@Think.COM Motivation for PARSE-BODY
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 10:00:52 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Wed, 30 Jul 86 13:00:36 edt
Date: Wed, 30 Jul 86 13:01 EDT
From: Guy Steele <gls@Think.COM>
Subject: Motivation for PARSE-BODY
To: Masinter.pa@Xerox.COM, common-lisp@sail.stanford.edu
Cc: gls@AQUINAS
In-Reply-To: <860728-140217-2923@Xerox>
Message-Id: <860730130117.1.GLS@BOETHIUS.THINK.COM>
Some of us, at least, use Lisp for the inventing of new embedded languages, and
one of the great things about Lisp is that is lets you get at various tools that
are used within the Lisp implementation itself (or were, at a time when a
particular paradigm was standard). Examples of these are READ, PRINT, PROGV,
ASSOC, and PAIRLIS. (You might not think of READ and PRINT as peculiarly part
of the interpreter, but consider how many language implementations have a very
complicated routine for reading and parsing programs but don't let the user get
at it? Consider APL, for example, whose program editor is not invocable by user
programs.)
If I want to invent my own interpreter (and I often do), having PARSE-BODY around
would be very convenient.
--Guy
∂30-Jul-86 1049 Masinter.pa@Xerox.COM Re: Motivation for PARSE-BODY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 10:48:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 86 10:47:07 PDT
Date: 30 Jul 86 10:46 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Motivation for PARSE-BODY
In-reply-to: Guy Steele <gls@Think.COM>'s message of Wed, 30 Jul 86
13:01 EDT
To: gls@Think.COM
cc: common-lisp@su-ai.ARPA
Message-ID: <860730-104707-1440@Xerox>
Guy,
I refer you to the compatibility note on pp 364-365 in a book written by
some random fellow, where there was a claim that "This design is an
attempt to make the reader as simple as possible to understand, use, and
implement." and "It is unnecessary, however, to cater to more complex
lexical analysis or parsing than that needed for Common Lisp."
Even if PARSE-BODY were as generally useful as, say, splicing reader
macros, the argument that it should be in Common Lisp because it >might
be convenient< for writers of embedded languages is a very weak one.
As has been pointed out, anyone who wants to write an embedded language
can write their own PARSE-BODY trivially relying only on MACROEXPAND and
a few CONSes and EQLs. Maybe we could even put PARSE-BODY it in the
(whatever-happened-to-the) yellow pages.
Just as Common Lisp doesn't provide built-in support for BNF parsing,
there's no reason to put something as awkward as parse-body into the
standard.
∂30-Jul-86 1137 gls@Think.COM Re: Proposal about lambda-list params
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 11:37:03 PDT
Received: from boethius by Godot.Think.COM via CHAOS; Wed, 30 Jul 86 14:37:02 edt
Date: Wed, 30 Jul 86 14:37 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: Proposal about lambda-list params
To: NGALL@G.BBN.COM
Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS
In-Reply-To: <[G.BBN.COM]29-Jul-86 09:50:57.NGALL>
Message-Id: <860730143746.5.GLS@BOETHIUS.THINK.COM>
Date: 29 Jul 1986 09:50-EDT
From: NGALL@G.BBN.COM
...
But under some of the new declaration-semantics proposals, the ignore
decl. would apply to only one of the parameters, thus given
(lambda (x y x z x) (declare (ignore x))...)
a compiler should still warn (or signal an error) that two of the
parameters illegally share a name. ...
Maybe one should have to write
(lambda (x y x z x) (declare (ignore x) (ignore x) (ignore x))...)
to suppress all warnings.
--Quux :-)
∂30-Jul-86 1252 DCP@QUABBIN.SCRC.Symbolics.COM Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 86 12:52:02 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25613; Wed 30-Jul-86 14:38:14 EDT
Date: Wed, 30 Jul 86 14:39 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
To: common-lisp@SU-AI.ARPA
Message-ID: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Alternate proposal that has a declarative syntax, and is probably a lot
more comprehensible.
[ &DECLARATIONS declares-var [ &DOC-STRING doc-string-var ]] &BODY body-var
If somebody wants to call it &DOCUMENTATION-STRING, go ahead; CLtL
usuually abbreviates "documentation-string" it to "doc-string".
Full semantics:
- Since &BODY can only be used in macros, these extensions may
only be used in macros.
- &DECLARATIONS may only appear if &BODY appears.
- &DOC-STRING may only appear if &DECLARATIONS appears.
- If any of these extensions appear, they appear in the order given, on
the grounds that is the normal order found within code. It probably
makes parsing defmacro's lambda-list a bit easier, and uniformity
will make code easier to understand by other than the author.
- declares-var is a catenation of the declarations. If the original
body had
(declare (ignore a))
(declare (ignore b) (inline aref))
then declares-var would get bound to
((ignore a) (ignore b) (inline aref))
- If &DOC-STRING is present, the first string of the unpruned body is
the documentation string, and parsing/pruning stops with the second
string, which is considered part of the implicit progn. [The
exception is a string that is the last form of the body, in that case
it is part of the implicit and not a doc-string, just like now.]
- If &DOC-STRING is not present, then the first string stops the
parsing/pruning of body. Any declares after a string are part of the
implicit progn and "are an error". Presumably the code that groks
implicit progns will complain about the presence of declares.
- body-var is the body without the declarations and/or doc-string, and
also with the first form NOT macroexpanded, even though
macroexpansion was necessary to search for declarations and
doc-strings. If the first form is a macro, it may get expanded
again. Tough, macros shouldn't have side effects.
I believe this nests correctly, as all the other defmacro destructuring
does. [Example deleted because even the simplest one is 16 lines long.]
I am willing to endorse this; I more-or-less believe it. I do not
believe the original
&BODY body-var [something-var [something-else-var]]
because it is totally lacking in syntax and comprehensibility.
Aside #1: I personally think &KEY and &BODY are mutually exclusive
because of their semantics; more-so when we worry about the presence of
declarations and a doc-string. This is because the semantics of a body
includes an implicit progn, whereas the semantics of keyword/values is of
markers and values. For those that do want &KEY and &BODY at the same
time it is probably necessary to require that the &KEY parsing happens
after the declarations/doc-string pruning.
Aside #2: If we had a simply specified PARSE-BODY, the simple
implementation of the above would be
(multiple-value-bind (declares-var doc-string-var body-var)
(parse-body original-body want-doc-string environment)
...)
I think we should have a (simply specified) PARSE-BODY even if (some)
extension to &BODY is adopted. The compiler and special-form groker
need them for the same reason users want them for defmacro. I think
PARSE-BODY and an &BODY extension should look very similar to each
other. I believe the ideas in this messages show such a similarity.
∂30-Jul-86 1259 berman@vaxa.isi.edu Conference
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 12:59:44 PDT
Received: by vaxa.isi.edu (4.12/4.7)
id AA27427; Wed, 30 Jul 86 12:59:35 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8607301959.AA27427@vaxa.isi.edu>
Date: 30 Jul 1986 1259-PDT (Wednesday)
To: common-lisp@su-ai.arpa
Cc:
Subject: Conference
Hi ya. I just found out that I'm going to the conference to meet with some
developers and what-not. So...I haven't been following the conference info
closely. Could somebody please post the times/locations for the Common Lisp
specific events?
Thanks.
RB
∂30-Jul-86 1330 berman@vaxa.isi.edu Conference
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:29:25 PDT
Received: by vaxa.isi.edu (4.12/4.7)
id AA27668; Wed, 30 Jul 86 13:29:14 pdt
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8607302029.AA27668@vaxa.isi.edu>
Date: 30 Jul 1986 1329-PDT (Wednesday)
To: common-lisp@su-ai.arpa
Subject: Conference
Hi ya. I just found out that I'm going to the conference to meet with some
developers and what-not. So...I haven't been following the conference info
closely. Could somebody please post the times/locations for the Common Lisp
specific events?
Thanks.
RB
∂30-Jul-86 1339 FAHLMAN@C.CS.CMU.EDU Handout at Lisp Conference
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:39:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 16:39:34-EDT
Date: Wed, 30 Jul 1986 16:39 EDT
Message-ID: <FAHLMAN.12226883945.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Handout at Lisp Conference
We plan to hand out the following informational flier at the Lisp
Conference registration. People who read it here won't have to take
one.
---------------------------------------------------------------------------
STATUS OF COMMON LISP STANDARDIZATION EFFORTS
Common Lisp is fast becoming a de facto standard for Lisp, especially in
the commercial world where the need for a standard, widely accepted Lisp
dialect has long been felt. Almost all Lisp suppliers in the U.S. now
offer, or intend to offer, implementations of Common Lisp. The language
is now available on most of the workstations and mainframes that are
used by the AI research community. Several Japanese companies have also
been active in Common Lisp development, and a Japanese standardization
committee has been established. Common Lisp is being used in Europe,
and the European efforts at Lisp standardization are taking Common Lisp
as one important input.
At a meeting in Boston in December, 1985, representatives from the
Common Lisp community agreed to form technical and steering committees
to work on Common Lisp standardization. The technical committee is to
develop a detailed language specification for Common Lisp; the steering
committee is to work on the non-technical aspects of the standardization
process. A group of people, including five key contributors to the
original Common Lisp design, was chosen to select the members for these
new committees; that task was completed in March of 1986.
The technical committee members are Alan Bawden, Daniel Bobrow, Richard
Gabriel, Martin Griss, David Moon, Jonathan Rees, Guy Steele, and Scott
Fahlman (chairman). The steering committee members are Richard Gabriel,
John McCarthy, Ronald Ohlander, Stephen Squires, Guy Steele, and Robert
Mathis (chairman). It is expected that some non-U.S. members will be
added to both committees in the near future. Both of these committees
are interim bodies that will be integrated into the normal standards
process, once that process is operating fully.
A formal proposal was made to X3, the accredited U.S. standards
committee for information processing systems, to establish a technical
committee for Common Lisp standardization. This proposal was accepted;
the Common Lisp committee is called X3J13. Plans are also being made
for the establishment of an international committee for Lisp
standardization under ISO. The formation of an X3 technical committee
is the normal way for the U.S. to participate in ISO activities.
Most of the technical discussion on Common Lisp occurs on the ARPAnet
via the mailing list "common-lisp@@sail.stanford.edu", administered by
Richard Gabriel (rpg@@sail.stanford.edu). A number of other networks
have mail gateways to the ARPAnet, making it possible for almost all
interested parties to participate in the technical discussions.
Electronic mail communication has been established with participants in
Japan and Europe.
The first meeting of X3J13, the U.S. Technical Committee for the
standardization of Lisp, will be Tuesday and Wednesday, September 23 and
24, 1986, in Washington, DC, at the headquarters of CBEMA, Suite 500,
311 First St, NW. On Tuesday (23) the meeting will be from 10am to 5pm;
on Wednesday (24) the meeting will be from 9am to 3pm. No special hotel
arrangements are being made.
Membership in X3 technical committees is open to all who actively
participate (attend meetings or correspond) and pay an annual service
fee (about $175). US citizenship or residency is not required. The
first meeting is important since policies and procedures for X3
technical committees will be discussed and specific plans for the Lisp
activity will be made.
Anyone interested in joining X3J13, and particularly anyone planning to
attend the first meeting, should contact the convenor for X3J13: Dr.
Robert Mathis, 9712 Ceralene Dr., Fairfax, VA 22032. Phone: (703)
425-5923. Arpanet: mathis@@b.isi.edu.
∂30-Jul-86 1356 FREEMAN@SUMEX-AIM.ARPA Re: Proposal #9: Variable Name Conflicts
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:55:37 PDT
Date: Wed 30 Jul 86 13:51:18-PDT
From: Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Subject: Re: Proposal #9: Variable Name Conflicts
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226683825.BABYL@C.CS.CMU.EDU>
Message-ID: <12226886097.79.FREEMAN@SUMEX-AIM.ARPA>
Fahlman wrote:
If I were to propose [something like let* can have repeated names],
it would be to treat all of the sequential binding forms (including
LAMBDA/DEFUN) in a consistent way.
Lambda and defun are not sequential binding forms; the order of
argument evaluation is irrelevant. "Lambda and defun are sequential
binding forms because the arguments they are applied to are evaluated
sequentially" is the only interpretation of Fahlman's statement I
could think of. I'm certain he had something else in mind; that's
much like Masinter's position which neither Fahlman nor I agree with.
I didn't think Fahlman's proposal 9B wording was unfair; some of his
"moderator's summary" wasn't as fair as it could have been. There is
a reason for Proposal 9; it just doesn't apply to let* or do*. (Under
Masinter's lambda model, all of 9 is wrong.)
Fahlman's concerns (about let* and do*) can be included as a warning
in the manual much like the *specials* *suggestion*. That's a
compromise 9B that I could live with.
Declarations (at least non-specials) should be decided before Proposal
9. I think pervasive declarations are a good idea and much more
important than 9A vs 9B. If we settle on 9A, then that argues
(weakly) against pervasive declarations. If we decide on pervasive
declarations, then 9A vs 9B goes on its merits.
-andy
-------
∂30-Jul-86 1400 jbarnett@nrtc Re: Proposal #9 Status: Variable Name Conflicts
Received: from NRTC.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 86 13:58:08 PDT
Date: Wed, 30 Jul 86 13:55:54 PDT
From: Jeff Barnett <jbarnett@nrtc>
To: common-lisp@SU-AI.ARPA
cc: Fahlman@C.CS.CMU.EDU
Subject: Re: Proposal #9 Status: Variable Name Conflicts
It was assumed in this and a previous message that looking for duplicate
names in the variable-list argument of a PROGV is an N**2 operation. Not
true. In the first place, if the list is short N**2 is small. In the
second place it can be done in N*log N time. To wit: (1) copy the list--
order n, (2) sort the list--order N*log N, and (3) search the ordered
list for adjacent duplicates--order N.
Jeff
∂30-Jul-86 1418 FAHLMAN@C.CS.CMU.EDU Proposal #9: Variable Name Conflicts
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 14:17:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 17:18:14-EDT
Date: Wed, 30 Jul 1986 17:18 EDT
Message-ID: <FAHLMAN.12226890971.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Andy Freeman <FREEMAN@SUMEX-AIM.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #9: Variable Name Conflicts
In-reply-to: Msg of 30 Jul 1986 16:51-EDT from Andy Freeman <FREEMAN at SUMEX-AIM.ARPA>
Lambda and defun are not sequential binding forms; the order of
argument evaluation is irrelevant. "Lambda and defun are sequential
binding forms because the arguments they are applied to are evaluated
sequentially" is the only interpretation of Fahlman's statement I
could think of. I'm certain he had something else in mind; that's
much like Masinter's position which neither Fahlman nor I agree with.
Well, DEFUN and LAMBDA are partly sequential-binding forms. They
process defaults and &aux vars sequentially. That's what I was
referring to.
-- Scott
∂30-Jul-86 1434 Gregor.pa@Xerox.COM Re: Motivation for PARSE-BODY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 86 14:34:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 86 14:29:22 PDT
Date: 30 Jul 86 14:28 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Motivation for PARSE-BODY
In-reply-to: Masinter.pa's message of 30 Jul 86 10:46 PDT
To: Masinter.pa@Xerox.COM
cc: gls@Think.COM, common-lisp@su-ai.ARPA
Message-ID: <860730-142922-1699@Xerox>
From: Masinter.pa
Even if PARSE-BODY were as generally useful as, say, splicing reader
macros, the argument that it should be in Common Lisp because it
>might
be convenient< for writers of embedded languages is a very weak one.
Independent of this sub-debate, I think the example the was already
given (by MLY I think) of:
(defmacro foo (&body body) (foo-internal body nil))
(defmacro foo* (&body body) (foo-internal body t))
(defun foo-internal (body sequentialp)
(multiple-value-bind (decls doc real-body) (parse-body body) ...)))
Is enough motivation for having PARSE-BODY.
∂30-Jul-86 1719 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #5 (aside)
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:19:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52899; Tue 29-Jul-86 22:46:42 EDT
Date: Tue, 29 Jul 86 22:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #5 (aside)
To: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
Message-ID: <860729224641.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #5: PARSE-BODY
....PARSE-BODY may perform macro-expansion (using the given
environment) in order to determine whether an initial macro-call expands
into a DECLARE form or documentation string.
Since when can macros expand into documentation strings?
∂30-Jul-86 1720 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:20:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52919; Wed 30-Jul-86 01:33:13 EDT
Date: Wed, 30 Jul 86 01:32 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14
To: Fahlman@C.CS.CMU.EDU
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
References: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>,
<12226310687.19.LOOSEMORE@UTAH-20.ARPA>,
The message of 25 Jul 86 00:30-EDT from Dave.Touretzky@A.CS.CMU.EDU,
<860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<RAM.12224974495.BABYL@C.CS.CMU.EDU>
Message-ID: <860730013252.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Proposals #5, #5A: PARSE-BODY
I think it's important to standardize on PARSE-BODY in some
form, distinct from &BODY. Most people probably wouldn't need
it, but those who did need it should -not- be encouraged to
write their own.
Don't call the argument DOCUMENTATION-ALLOWED-P. The issue
isn't whether a doc string is accepted, it's whether a string
in that position should be assumed to be a doc string or
assumed to be a literal constant. (DEFUN FOO (X) "hi" X)
would be a valid program even if there were no such thing
as a doc string. Call the arg PARSE-DOCUMENTATION-P.
The additional return values suggested in proposal 5A seem
misguided to me. I prefer returning just body, declares,
and doc in that order.
I think the BODY should be a list of forms with the first
form potentially macroexpanded since the pre-expanded form
is easy to recover by doing something like:
(CAR (LAST (LDIFF unparsed-body (CDR parsed-body))))
Actually, though, the macro might have smashed the macro
call's argument list, perhaps not even leaving it in a
semantically meaningful form, though more commonly just
displacing the macro expansion in place. So claiming you
were going to return an unexpanded form would be impossible
to really do in the general case.
Related questions: Is there anything in CLtL that specifies
that the "foo" in (LAMBDA FOO () "foo") has a body form of
"foo" and not just a doc string of "foo" with a null body list?
Is there anything that says whether
(LAMBDA (X) "foo" (DECLARE (IGNORE X)))
is well-formed or what it returns? Regardless of the answers
to these questions, having PARSE-BODY around would mean that
individual users would not have to develop private heuristic
solutions.
When everyone's done with this initial round of comments,
I'd want to see a reworked proposal so that I could give
a boolean vote.
Proposal #6: Parsing in &BODY
I strongly lean toward the syntax I proposed. In addition to
the issues of upward-compatibility with existing code and the
argument about symmetry with &REST, it just involves less parens.
Also, I'm inclined to agree with Sandra that &REST and &BODY
need not be mutually exclusive. This would be properly consistent
with the conjoined use of &REST and &KEY, and with the conjoined
use of &WHOLE and other arguments.
Proposal #7: TYPE-SPECIFIER-P
I agree with Moon that this should only be called TYPE-SPECIFIER-P
if it were going to really predicate type expressions and not type
symbols. I'm content to include only TYPE-NAME-P for now. The need
for this comes up in my error proposal implementation in a situation
where SYMBOLP ends up sufficing (modulo reduced error checking). I
think TYPE-NAME-P is an important primitive to have.
Proposal #8: Clarifications to DEFCONSTANT
I concur with most of Moon's remarks here. Also, I think it's pretty
clear that EQUAL is an acceptable predicate since even in the case of
(DEFCONSTANT FOO (LIST 'A 'B))
where the person is obviously going to work to get something less
EQL than
(DEFCONSTANT FOO '(A B))
would have gotten him, the compiler is under no contract to preserve
that absence of sharing in the inlined code it outputs to binary files.
Perhaps we should say explicitly that it is an error to side-effect
a system constant, and permit systems to warn in compiled code about
things like (SETF (CAR FOO) 3), to signal an error at runtime (eg, by
putting such constants in read-only areas), etc.
I would prefer that the warning about redefining a constant be
refined to make the "is an error" part dependent on whether the programs
have made assumptions about the value of the constant, not just whether
they refer to the constant. eg, macros might have called functions which
use the old value even if they do not themselves refer to the constant
explicitly.
I would also prefer that the warning about redefining constants refer
not only to compiled code being invalidated but also to interpreted code.
If particular implementations happen to not make assumptions about
constants in interpreted code, that's ok but should not be part of any
guarantee offered by CL. That way, implementations are not precluded from
doing prelimary Scheme-style semantic analysis even in interpreted code.
Proposal #9, #9A, #9B: Variable Name Conflicts
My feeling is that &AUX and LET* should not be subject to the variable
name conflict rule. I agree with completely with Dave Touretzky's comment
that "outlawing duplicate names in LET* promotes too shallow a notion of
consistency: one based on syntax rather than semantics."
The case of DO* is interesting. Although superficially this seems similar
to DO in the same way as LET* is to LET, I think at a deeper level it is
not quite as analagous. Could someone please explain to me what a repeated
variable would mean? Would the second one be a side-effect at the same
level or would it actually shadow something? If shadowed, is the shadowing
magically undone when you get to stepping the variable or do both steps
refer to the value of the second variable in the init column? Unless
someone can suggest a meaning for repeated variables in this context, I'd
suggest that repeated var names in DO* be made illegal even if it's allowed
in &AUX and LET*.
In my mind, there's no real basis for Masinter's claim that the
declaration issue needs to get involved here. If you have
(DEFUN FOO (X &AUX (X (F X)) (X (G X))) (DECLARE (SPECIAL X)) (H X))
and you're wondering which of F, G, and H will see the special X, I
think we should say arbitrarily -- only H. People should break up the &AUX
into nested LET expressions with explicit declarations as appropriate if
they want otherwise. Ditto for LET*.
I cannot agree to any of #9, #9A, or #9B.
Proposal #10: Forms That Allow Declarations
I'd like to see declarations allowed in a LABELS or FLET.
I agree with those who've suggested that this would not be appropriate for
MACROLET. Unlike FLET, LABELS, LET, etc. which introduce semantic terms,
MACROLET introduces only syntactic terms. If DECLARE was ever needed
inside a MACROLET, it is probably just a coincidence and not a result
of the MACROLET.
Proposal #11: Contents of Tagbody
I hate arbitrary little rules that say things like only symbols and
integers are allowed. The reason we can get away with tags at all
is that they're atoms and atoms can't have side-effects. I think all
atoms should be allowed here. I think we should just define the
predicate that gets used, and I think the predicate should be EQL.
Maybe someone will come up with a creative use of character objects
as tags. I see no reason to preclude that.
I note that in your proposal 12, you say "... the same (EQL) tag ...",
and I put that forth as evidence that this is how people already like
to think about tag equivalence.
Proposal #12: Unique Names For Tags
This seems non-controversial.
Proposal #13: Structure Sharing in Arguments
In the case of &REST in macros, I see no reason to not simply say
that the argument list is -always- shared. Is there an argument for
why this might not always be possible? In the case of &BODY, it may
not be possible to do the sharing, so I'm willing to leave this
undefined and say it "is an error" to modify the list.
For a function that takes &REST arguments, I would prefer that a copy
always be made unless the interpreter or compiler can prove that it
won't be necessary. If we cannot agree to do that, then it must be
noted both that it "is an error" to modify such a list AND that it
is an error to pass such a list to someone else using APPLY and then
later modify it. eg, (PROGN (APPLY #'FOO L) (SETF (CDR L) ...))
may screw up state that FOO has encached for later use.
Proposal #14: THE and VALUES
I'm not happy with this form of the clarification.
I agree with Moon that the discussion of &keywords in the VALUES
declaration seems pretty out of place. We don't check number of return
values or do &keyword-hacking on return values anywhere else so
doing it here seems out of place.
If we did keep it, though, I'd want (THE type form) to be equivalent
to (THE (VALUES type &REST T) form) and would want any use of
(VALUES ...) to mean that I expected exactly the indicated number
of values.
Others seem to be disagreeing, though, so it may be better to agree
to think harder on the issue and for now not bother to try gratuitously
"clarifying" something we don't adequately understand.
∂30-Jul-86 1720 BSG@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: exit-to-system
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:20:38 PDT
Received: from SORA.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53172; Wed 30-Jul-86 12:12:39 EDT
Date: Wed, 30 Jul 86 12:12 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: exit-to-system
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA,
common-lisp@SU-AI.ARPA, gls%aquinas.think.com@CSNET-RELAY.ARPA,
ida%u-tokyo.junet@CSNET-RELAY.ARPA
In-Reply-To: <8607290714.AA22657@ccut.u-tokyo.junet>
Message-ID: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM>
Date: Tue, 29 Jul 86 16:14:11+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Date: Mon, 21 Jul 86 15:01 EDT
From: Guy Steele <gls%ZARATHUSTRA.THINK.COM@u-tokyo.junet>
Subject: Re: exit-to-system
...
Well, we do have ED, which is clearly a user-interface thing.
Here is a stab at defining QUIT:
QUIT [Function]
This function is intended to terminate the running Lisp system in some
appropriate manner. ...
...
--Guy
I agree. The name QUIT sounds reasonable.
ida@utokyo-relay.csnet
-----
The name QUIT does not sound reasonable. Quit what? Is ease of typing
an issue, for something which is typed once per session and probably
appears once in even the largest subsystem? EXIT-LISP sounds much
better. I can easily (and have) had internal functions, and macros
called QUIT. I don't think the name should be used up in this way.
∂30-Jul-86 1720 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Status of declare UNSPECIAL
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 30 Jul 86 17:20:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53212; Wed 30-Jul-86 12:27:06 EDT
Date: Wed, 30 Jul 86 12:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Status of declare UNSPECIAL
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860725110937.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <860730122659.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 25 Jul 86 11:09 EDT
From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
For the record, I also remember that we decided explicitly not to have
an "UNSPECAL" (whatever you call it) declaration, and I also don't
remember why. Unfortunately, I remember this discussing occurring
during a physical meeting, but someone should poke into the old archives
and see if there was any good reasoning that we should all know about.
Otherwise, I agree that there should be such a declaration.
I don't remember either, but here is my guess. Maclisp and Zetalisp
declaration scoping follows essentially the rules proposed by Bawden, in
which all declarations are pervasive, and therefore they need UNSPECIAL.
Once you switch to the current Common Lisp rules, in which a binding
of a variable shadows a SPECIAL declaration of the same name in an outer
contour, and creates a lexical binding rather than a special binding, you
no longer need an UNSPECIAL declaration to get that lexical binding.
UNSPECIAL was probably removed because of the mistaken argument that
the above implies that UNSPECIAL is never needed. It is still possible
to concoct more complicated situations where UNSPECIAL would not be a
no-op in the current Common Lisp rules, which I think all involve UNSPECIAL
applying to references rather than to a binding. Also of course UNSPECIAL
is the only way to shadow a SPECIAL proclamation, but perhaps it was
considered undesirable to allow that.
Among the declaration types listed in chapter 9, the only ones that
cannot be turned off by another declaration are SPECIAL, IGNORE, and
DECLARATION.
I'm not taking a stand on whether UNSPECIAL should or should not be included
in the language, especially not until we have settled the scoping rules
for declarations, but I thought the above facts and conjectures might
be interesting.
∂30-Jul-86 2018 FAHLMAN@C.CS.CMU.EDU Proposal #5 (aside)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 86 20:17:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 30 Jul 86 23:17:51-EDT
Date: Wed, 30 Jul 1986 23:17 EDT
Message-ID: <FAHLMAN.12226956455.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Proposal #5 (aside)
In-reply-to: Msg of 29 Jul 1986 22:46-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Since when can macros expand into documentation strings?
My reading of the manual on this point may be faulty or perhaps
"rabbinical", but here is what I think the book says:
On page 154, it says that it is permissible for a macro call to expand
into a declaration and be recognized as such, provided that the macro
call appears where a declaration may legitimately appear.
On page 67 it says that declarations may follow a doc string.
Suppose you have
(defun foo (...)
(MACRO1 ...)
(MACRO2 ...)
... more forms...)
Suppose MACRO1 expands into a string and MACRO2 expands into a DECLARE
form. If we expand MACRO1 and get a string, I would say that this is
the documentation string and we should then expand MACRO2 to see if it
is a declaration, since it is in a place where a declaration may
legitimately appear. That seems like the most reasonable interpretation
to me. I agree that we could say that a string obtained from a leading
MACRO is not allowed to be a doc-string, in which case it is a body form
and we can stop looking for macros.
The book doesn't seem to come down on one side or the other. Note,
however, that it is allowed to expand all the macros at defun time (some
implementations actually do this), and in that case my interpretation
would fall out automatically unless special care is taken to disallow
this.
-- Scott
∂31-Jul-86 0451 @MCC.COM,@HAL.MCC.DialNet.Symbolics.COM:Loeffler@[10.3.0.62] Re: exit-to-system
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 31 Jul 86 04:51:49 PDT
Received: from HAL.MCC.DialNet.Symbolics.COM (HAL.CAD.MCC.COM.#Internet) by MCC.COM with TCP; Thu 31 Jul 86 06:52:37-CDT
Date: Thu, 31 Jul 86 06:51 CDT
From: David D. Loeffler <Loeffler@[10.3.0.62]>
Subject: Re: exit-to-system
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM>
Message-ID: <860731065106.0.LOEFFLER@HAL.MCC.DialNet.Symbolics.COM>
Reply-To: Loeffler@[10.3.0.62]
Postal-address: P.O. Box 200195, 9430 Research Blvd., Austin, TX 78720
Date: Wed, 30 Jul 86 12:12 EDT
From: Bernard S. Greenberg <BSG@STONY-BROOK.SCRC.Symbolics.COM>
The name QUIT does not sound reasonable. Quit what? Is ease of typing
an issue, for something which is typed once per session and probably
appears once in even the largest subsystem? EXIT-LISP sounds much
better. I can easily (and have) had internal functions, and macros
called QUIT. I don't think the name should be used up in this way.
I agree with Bernie on this one. EXIT-LISP is better than QUIT. I used
to work on a system that had a very uniform command set and QUIT meant
"exit" from almost every one of the subsystems. Other system used EXIT.
If a programmer wants to put an escape out of lisp in their code then
EXIT-LISP is the right thing. Vendors may wish to incorporate their own
QUIT or EXIT functions so that users will know how to get out of the
interpreter.
-- Dave
∂31-Jul-86 1143 alatto@cc5.bbn.com Re: #13, #14
Received: from BBNCC5.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 11:42:51 PDT
To: Kent M Pitman <KMP@scrc-stony-brook.ARPA>
cc: Common-Lisp@su-ai.ARPA
Subject: Re: #13, #14
In-reply-to: Your message of Wed, 30 Jul 86 01:32 EDT.
<860730013252.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
References: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>,
<12226310687.19.LOOSEMORE@UTAH-20.ARPA>,
The message of 25 Jul 86 00:30-EDT from Dave.Touretzky@A.CS.CMU.EDU,
<860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<RAM.12224974495.BABYL@C.CS.CMU.EDU>
Date: 31 Jul 86 14:26:30 EDT (Thu)
From: Andy Latto <alatto@cc5.bbn.com>
Proposal #13: Structure Sharing in Arguments
Kent says:
...
For a function that takes &REST arguments, I would prefer that a copy
always be made unless the interpreter or compiler can prove that it
won't be necessary. If we cannot agree to do that, then it must be
noted both that it "is an error" to modify such a list AND that it
is an error to pass such a list to someone else using APPLY and then
later modify it. eg, (PROGN (APPLY #'FOO L) (SETF (CDR L) ...))
may screw up state that FOO has encached for later use.
I don't see why allowing the &rest list to be the same list that was
passed to apply requires any of the above suggestions about what "is an error".
Lisp functions are allowed to modify their arguments, or save them for
later use. Proposal 13 says that APPLY, like NCONC, is such a function in
the case where the function being APPLYed does destructive operations on
its &rest argument. (apply #'rplacd args) and (apply #'foo args) both
modify their arguments if foo is a function that does destructive
operations on its &rest argument, and I don't see a big difference
between them. In general, if I write a function that destructively
modifies its arguments (or use an existing one, like NCONC), I
must be careful that no other part of the code assumes that the
structure I have modified will not change. If you use argument-modifing
functions recklessly, you will produce obscure, hard-to-find, bugs. This is
certainly true of normal arguments to functions, and I don't see why it
shouldn't be true of &rest arguments as well, particularly if it can make
some implementations more efficient.
I also believe their should be some kind of &temp-rest lambda
list keyword that produces an &rest list with dynamic extent, but that's
a separate proposal that should be dealt with later.
Proposal #14: THE and VALUES
The purpose of THE is to give the compiler or interpreter
information on the type of the value(s) returned by the form, since
this may help produce more efficient code. Information on the
number of values reuturned can presumably be put to similar use.
It would be nice to have syntax to say either "These are the
types of the first two returned values, and I don't know the types
of any others, if any" or "Exactly two values will be returned, and here
are their types". (THE (VALUES type1 type2 &rest T)) and
(THE (VALUES type1 type2)) seems like as good a syntax as any
for expressing these two concepts.
I have no strong feelings as to whether (THE type1) should
be equivalent to (THE (VALUES type1)) or (THE (VALUES type1 &rest T)).
On the subject of VALUES, I noticed that Cltl says, on the
issue of checking the type of the value(s) returned by a form in a
THE special form, "Implementations are encouraged to make an explicit
error check when running interpretively" (P 163). It seems to me that this
check should be made if it is declared (optimize (safety 3) (speed 0)),
and should not be made if it is declared (optimize (safety 0) (speed 3)), regardless
of whether it is interpreted or compiled, and that the reference to the
interpreter should be removed.
Andy Latto
alatto@bbn.ARPA
∂31-Jul-86 1502 @QUABBIN.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM Re: Staus of proposals 10, 11, and 12
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 14:59:57 PDT
Received: from CREEPER.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26022; Thu 31-Jul-86 15:03:33 EDT
Date: Thu, 31 Jul 86 15:04 EDT
From: dcp@TENEX.SCRC.Symbolics.COM
Sender: Zippy@TENEX.SCRC.Symbolics.COM
Subject: Re: Staus of proposals 10, 11, and 12
To: NGALL@G.BBN.COM, Common-Lisp@SU-AI.ARPA
cc: Fahlman@C.CS.CMU.EDU
In-Reply-To: <[G.BBN.COM]29-Jul-86 21:47:02.NGALL>
Message-ID: <860731150441.4.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM>
Date: 29 Jul 1986 21:47-EDT
From: NGALL@G.BBN.COM
Date: Tue, 29 Jul 86 11:50 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
I may have thought of one usage:
(macrolet ((print-them (list)
`(mapc #'print ,list)))
(declare (notinline mapc))
...)
If anybody else believes this, perhaps it should be one of the examples?
I don't believe it. The stuff inside the backquoted list is not code,
it is data. Here's a similar one that I believe:
(macrolet ((print-them (list)
`(progn ,@(mapcar #'(lambda (item) `(print ',item))
list)))
(declare (notinline mapcar))
...)
In this, the mapcar funcall form IS code.
You misunderstand. Declarations have a scoping for code that it sees.
My intention was that anybody who calls (print-them some-list) expands into
(mapc #'print some-list)
and that the declaration forces MAPC to be open coded. Your definition
has two differences from mine: (1) Your declaration tries to affect the
expansion PROCESS (mine affects the processing of the expansion), and
(2) your contract is different than mine (mine takes a runtime list,
your's takes a compile time list). To get (1), I claim your declaration
is in the wrong place. It should have been
(macrolet ((print-them (list)
(declare (notinline mapcar))
`(progn ,@(mapcar #'(lambda (item) `(print ',item))
list))))
...)
Note that this still is not
a strong argument for decls in the body of a macrolet, since the decl
could have been put in the body of the print-them macro definition.
"must" not "could"
But I agree that we should allow decls in the body of a macrolet.
∂31-Jul-86 1506 @QUABBIN.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM Proposal #5 (aside)
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 15:06:43 PDT
Received: from CREEPER.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26023; Thu 31-Jul-86 15:07:00 EDT
Date: Thu, 31 Jul 86 15:08 EDT
From: dcp@TENEX.SCRC.Symbolics.COM
Sender: Zippy@TENEX.SCRC.Symbolics.COM
Subject: Proposal #5 (aside)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
common-lisp@SU-AI.ARPA
In-Reply-To: <860729224641.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <860731150815.5.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM>
Date: Tue, 29 Jul 86 22:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Proposal #5: PARSE-BODY
....PARSE-BODY may perform macro-expansion (using the given
environment) in order to determine whether an initial macro-call expands
into a DECLARE form or documentation string.
Since when can macros expand into documentation strings?
Sidestepping the issue of whether or not it is currently allowed, I see
no reason it shouldn't be allowed. Consider a program-writing-program
that generates some code like
(defun helper-function-259 (...args...)
(declare (safety 2) (speed 1))
(compute-documentation-string :safety 2 :speed 1
:parent "helper-function"
:contract "factor the number 259")
(declare (inline aref))
...)
∂31-Jul-86 1514 hoey@nrl-aic Proposal #9: Fast testing in PROGV
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 15:14:29 PDT
Date: Thu, 31 Jul 86 18:11:20 edt
From: Dan Hoey <hoey@nrl-aic>
Message-Id: <8607312211.AA13507@nrl-aic>
To: jbarnett@nrtc.ARPA, common-lisp@su-ai.ARPA
Subject: Proposal #9: Fast testing in PROGV
From: Jeff Barnett <jbarnett@nrtc>
It was assumed in this and a previous message that looking for
duplicate names in the variable-list argument of a PROGV is an
N**2 operation.... It can be done in N*log N time.
You can put a mark on the property lists of the variables
for a linear algorithm.
Dan
∂31-Jul-86 1533 @YUKON.SCRC.Symbolics.COM:Zippy@TENEX.SCRC.Symbolics.COM Re: Proposal #9 Status: Variable Name Conflicts
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 15:33:39 PDT
Received: from CREEPER.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66534; Thu 31-Jul-86 14:59:38 EDT
Date: Thu, 31 Jul 86 14:59 EDT
From: DCP@TENEX.SCRC.Symbolics.COM
Sender: Zippy@TENEX.SCRC.Symbolics.COM
Subject: Re: Proposal #9 Status: Variable Name Conflicts
To: Common-Lisp@SU-AI.ARPA, Jeff Barnett <jbarnett@NRTC.ARPA>
In-Reply-To: The message of 30 Jul 86 16:55 EDT from Jeff Barnett <jbarnett@nrtc>
Message-ID: <860731145915.3.LISP-MACHINE@CREEPER.SCRC.Symbolics.COM>
Date: Wed, 30 Jul 86 13:55:54 PDT
From: Jeff Barnett <jbarnett@nrtc>
It was assumed in this and a previous message that looking for duplicate
names in the variable-list argument of a PROGV is an N**2 operation. Not
true. In the first place, if the list is short N**2 is small. In the
second place it can be done in N*log N time. To wit: (1) copy the list--
order n, (2) sort the list--order N*log N, and (3) search the ordered
list for adjacent duplicates--order N.
Any implementation that did this would probably discourage users from
using PROGV because it would be costly (inefficient) to use. copying
the list conses and takes time. Sorting can potentially cons, may be
NlogN, but is quite expensive in the smaller cases. PROGV has so real
and valid uses; it should be relatively inexpensive to use.
I think PROGV should be removed from the list of forms that check for
variable name conflicts. I think variable name conflicts should be
detected by the compiler; not the runtime system. I think the semantics
of PROGV are that the LAST symbol/value pair takes presedence in case
there is more than one pair for a given symbol.
∂31-Jul-86 1827 FAHLMAN@C.CS.CMU.EDU Proposal #9 Status: Variable Name Conflicts
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 18:27:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Jul 86 21:27:32-EDT
Date: Thu, 31 Jul 1986 21:27 EDT
Message-ID: <FAHLMAN.12227198519.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Proposal #9 Status: Variable Name Conflicts
In response to: DCP@TENEX.SCRC.Symbolics.COM
I think PROGV should be removed from the list of forms that check for
variable name conflicts. I think variable name conflicts should be
detected by the compiler; not the runtime system. I think the semantics
of PROGV are that the LAST symbol/value pair takes presedence in case
there is more than one pair for a given symbol.
As I said in response to this question earlier, nobody is proposing a
"list of forms that CHECK FOR variable name conflicts". There is a
proposal for forms in which the use of duplicate variable names "is an
error". Not the same thing.
-- Scott
∂31-Jul-86 1848 FAHLMAN@C.CS.CMU.EDU What's going on?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 18:47:32 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 31 Jul 86 21:47:43-EDT
Date: Thu, 31 Jul 1986 21:47 EDT
Message-ID: <FAHLMAN.12227202184.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: What's going on?
Several people have asked what became of the summaries I promised for
issue #14 and for the declaration scope stuff.
I have not sent these out yet. It has become clear to me that the
discussion/decision process is not working at all well: the mail volume
is too high, the load on the moderator is MUCH too high, the rate of
progress is negligible, a lot of time is being wasted discussing issues
that don't really matter, and my efforts to improve all this have
antagonized a lot of people without solving any of the problems.
My top-level task right now is to discuss these problems with the
technical committee members and others to see if we can figure out some
procedural changes that will get things moving in useful directions with
less wear and tear on everyone. Until we've decided how to proceed,
I won't be pushing too hard to make progress on specific technical
issues.
-- Scott
∂31-Jul-86 1943 NGALL@G.BBN.COM Re: declarations in macrolet puzzle
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 19:39:22 PDT
Date: 31 Jul 1986 22:39-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: declarations in macrolet puzzle
From: NGALL@G.BBN.COM
To: MASINTER.PA@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]31-Jul-86 22:39:13.NGALL>
In-Reply-To: <860730-064109-1194@Xerox>
Date: 30 Jul 86 6:40:17 PDT
From: MASINTER.PA@Xerox.COM
(macrolet ((specials () (specials) '(declare (special special-list ,@special-list))))
(specials)
special-list))
...
The missing piece to your puzzle is that declarations are expanded
BEFORE any bindings take place (perhaps this should be stated
explicitly in CLtL). Thus, the call to specials in the body of the
macrolet does NOT refer to the specials being bound in the head of
macrolet. This is true, not only of bindings made by macrolet, but
also those made by let, flet, etc.
-- Nick
∂31-Jul-86 1949 NGALL@G.BBN.COM Re: Declarations in MACROLET
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 19:49:05 PDT
Date: 31 Jul 1986 22:49-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Declarations in MACROLET
From: NGALL@G.BBN.COM
To: RAM@C.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]31-Jul-86 22:49:06.NGALL>
In-Reply-To: <RAM.12226812298.BABYL@C.CS.CMU.EDU>
Date: Wed, 30 Jul 1986 10:05 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
I don't think that it would be correct for a declaration at the
head of a macrolet to affect the bodies of any of the macros, since
the bodies of the macros are defined to be in the null environment.
You raise an interesting question:
(flet ((foo ()))
(locally (declare (inline foo))
(macrolet ((bar () (foo 1 2 3)))
(foo)...)))
Currently, does the inline decl affect both calls to foo? I can't
tell from CLtL.
-- Nick
∂31-Jul-86 2155 FAHLMAN@C.CS.CMU.EDU Japanese Subset Proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 86 21:55:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 Aug 86 00:55:43-EDT
Date: Fri, 1 Aug 1986 00:55 EDT
Message-ID: <FAHLMAN.12227236417.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Japanese Subset Proposal
Profesor Masayuki Ida, the chairman of the Common Lisp subcomittee of
JEIDA in Japan, has sent me a draft of a subset proposal that a number
of Japanese researchers have been working on. He is interested in
discussing this with the U.S. Common Lisp community, and especially
those people interested in subsets. The proposal is too long to send to
the whole Common-Lisp mailing list, so I have put it on C.CS.CMU.EDU
as file "prva:<slisp.standard>japan-core.txt". Discussion of this
proposal should probably take place on the CL-SUBSET mailing list.
-- Scott
∂31-Jul-86 2211 KMP@YUKON.SCRC.Symbolics.COM Comments on DCP's revised &BODY proposal
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 31 Jul 86 22:10:47 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66811; Fri 1-Aug-86 00:45:01 EDT
Date: Fri, 1 Aug 86 00:44 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Comments on DCP's revised &BODY proposal
To: DCP@SCRC-QUABBIN.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860801004440.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I mostly like this variation of the &BODY proposal.
I would prefer the name &DOCUMENTATION.
In fact, given that we have &ENV instead of &ENVIRONMENT, it might be more
consistent to have a short names like &DOC and &DECLS. I'm won't champion
that very strongly, but I think it's worth pointing out both for the sake
of consistency and the sake of reducing indentation. By using &DOCUMENTATION
and &DECLARATIONS you're virtually assuring that things like:
(DEFUN SOMETHING (NAME BVL &DECLARATIONS DECLS &DOCUMENTATION DOC &BODY FORMS)
...)
will be pushing the right margin on an 80-column screen even given reasonably
concice choices of macro and variable names.
In the presence of displacing macros, I feel fairly strongly that we can't
currently guarantee that the &BODY will contain unexpanded forms. My feeling
is that we should either guarantee that the expanded (rather than unexpanded)
form be returned if an expansion happened, or that we should be explicitly
vague. It would be very unwise to document something we couldn't reliably
provide.
With regard to your aside about &KEY, I agree that &KEY and &BODY should be
exclusive. Alternatively, though, we could revise the description of &KEY to
do something useful. It comes up in the current error proposal that there
are a lot of forms with bodies that have leading keywords. ie,
(name bvl :key1 :value1 :key2 :value2 ... . body)
The body is defined to start when the keyword pairs run out. Right now, these
have to be "manually" parsed. It would be amazingly convenient to be able to
say
(NAME BVL &KEY KEY1 KEY2 &BODY FORMS)
I'd be content for now to just leave this syntax undefined and let people
think about a proposal on this subject later, but my desire to have this
work makes this it seem very desirable to at least just disallow the current
meaning to a coupled &BODY/&KEY configuration for the interim.
∂31-Jul-86 2229 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 31 Jul 86 22:29:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54292; Thu 31-Jul-86 17:01:24 EDT
Date: Thu, 31 Jul 86 17:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860730143900.6.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860731170132.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I believe that Plummer's suggestion of adding &DECLARATIONS and &DOC-STRING
is superior to the previous two proposals for extensions to DEFMACRO for
parsing bodies.
I disagree with Plummer's suggestion that &KEY and &BODY are mutually
exclusive. The semantics of &BODY is not an implicit progn; the only
semantics of &BODY involves code formatting and indentation (CLtL p.145).
I agree that &KEY and &DECLARATIONS are mutually exclusive.
∂31-Jul-86 2230 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM QUIT
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 31 Jul 86 22:29:23 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54240; Thu 31-Jul-86 16:05:24 EDT
Date: Thu, 31 Jul 86 16:04 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: QUIT
To: Common-Lisp@SU-AI.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA
References: <860730121244.3.BSG@SORA.SCRC.Symbolics.COM>,
<8607290714.AA22657@ccut.u-tokyo.junet>
Message-ID: <860731160402.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I'm sorry, but I just will not support the idea of a single function QUIT
as is currently being discussed. If the problem were re-cast, it might be
soluble, but I believe the problem as I've seen it stated thus far is just
plain insoluble.
I base my criticisms on experience that I have from create a portable
QUIT function for use in Macsyma internals. I created such a function
using various non-portable primitives provided by particular dialects
I was studying. As with the GC problem, I found that the idea seemed
superficially plausible but just didn't work out in practice. Here are
some of my observations and conclusions ...
1. Where is control transfered?
Of the implementations which primitively offer some variant of QUIT,
all that I know of are on partitioned address space machines which
have a basically tree-structured process system that offers a
distinguished superior (usually an exec) to which it is obvious that
control should be transfered upon call to QUIT.
Shared address space machines (ie, Lisp Machines) have the problem
that there is no tree of processes. All occupy an equal status and
there is no obvious process to which control should be returned.
2. What is a process?
On partitioned address space machines, each process typically
comes with its own "global" state. Killing a process means killing its
"global" state. On shared address machines, killing the process will
generally kill only its dynamic state, not its global state (which
is generally intertwined with the global state of other processes).
To kill its global state means killing the global state of sibling
activities, which may be highly undesirable.
3. Can the process be resumed?
Even among partitioned address space machines, there is disagreement
about whether exiting (to the exec) means that you can re-enter later.
4. What does it mean for a process to be resumed?
Presumably resuming leaves the global state intact. Does it restart
the process or does the call to QUIT just return NIL?
5. If a process is killed permanently, are the associated UNWIND-PROTECT
cleanup forms guaranteed to run first?
Obviously, some of these issues cannot be answered by the Common-Lisp
committee. They are architectural issues beyond the scope of the
language. If we standardize on any meaning for QUIT, however, it must be
guided by an understanding that people do not use linguistic primitives
in the absence of intent, and that we should not provide primitives
which do not allow the programmer to clearly specify some meaningful
intent. In light of the questions I've raised above, I hope it's clear
that definitions like "Exits the Lisp system" do not make any intent
clear.
Here are some real-life scenarios that I see...
1. If the intent was to exit, what if there was no place to go?
On the 3600, the Lisp Listener doubles as an exec. It is the
standard place to which programmers return to give commands,
not a place to be returned from. Having a "user interface"
function named QUIT which was a no-op when typed to Lisp would
be very confusing. Having it randomly select another activity
would be fairly useless. I feel that people don't interactively
ask to exit something unless they think there is an obvious
place to go.
2. If the intent is to exit temporarily and the exit turns out to
be permanent, this can have remarkably drastic consequences. A
user of Macsyma would be phenomenally irritated if I offered a
temporary-exit function and it ended up exiting permanently
before s/he had a chance to save the MACSYMA's state.
3. If the intent was to exit permanently and the program was
allowed to proceed, the effects of continuing could be very
strange. I've found myself resorting to things like:
(PROGN (QUIT) ;Try a permanent exit
(...)) ;If we got here, the QUIT didn't work,
;so try cleaning up enough to continue
or even:
(LOOP (QUIT)) ;Insist on a permanent exit!
4. If the intent was to exit "lisp" permanently, destroying global
state, I'd argue that it could not possibly have been the intent
of any portable program to really kill everything on the machine
since those other things are beyond the scope of Common Lisp and
not something that CL programs have any obvious way to reason
about.
On the 3600, you can't opt to "start over" without taking the
Editor, Mail Reader, Peek, Telnet Windows, etc. with it. Some
people here at Symbolics do all their work from the same Lisp for
several weeks at a time, building up lots of state which they
don't want thrown away casually. There is no "starting over" that
is not synonymous with "cold booting". In the case of server
machines, this would mean that file connections would be broken,
mail would stop being delivered until the (sometimes long) cold
boot sequence had run, etc. In fact, the boot sequence may not
begin automatically just because I halt my machine. If I was
dialing in from home, I might have to go to work to initialize
the system again.
Some non-Lispms have an in-Lisp editor even though they have
other processes which are separable. Perhaps some of those
users use that editor only for editing Lisp and are content to
have the editor and the lisp go away as a unit because they do
other text editing in an editor that doesn't go away with Lisp,
but that's presumably a property of the user rather than the
system.
The real problem here is that there is no such thing as exiting in the
pure abstract. Exiting means to pass through an abstract boundary
between an abitrarily chosen inside and outside. In the CL spec, we have
remained intentionally silent on the issue of where that line is drawn
in order to accomodate both Lispm-based and conventional systems. I
think that corollary to this silence is the fact that functions which
attempt to cross the boundary are ill-defined. Not only do some systems
draw the boundary in different places than others, but some
intentionally don't draw it at all.
I don't care whether the primitive is called QUIT, EXIT, EXIT-TO-SYSTEM,
or whatever. The names themselves are not the problem. I only care that
any names we choose have a very clear behavior and that I can reason
about at coding time, or that my programs can reason about at runtime
prior to actually invoking the primitive which actually attempts to exit.
I don't plan to seriously consider any proposal for a QUIT primitive
which does not carefully address these issues.
∂01-Aug-86 0357 hpfclp!hpfcjrd!diamant@hplabs.HP.COM Proposal #13: Structure Sharing in Arguments
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 1 Aug 86 03:41:58 PDT
Received: by hplabs.HP.COM ; Fri, 1 Aug 86 03:40:43 pdt
Received: from hpfcjrd.UUCP; Thu, 31 Jul 86 23:49:27
Received: by hpfcjrd; Thu, 31 Jul 86 23:49:27 mdt
Date: Thu, 31 Jul 86 23:49:27 mdt
From: John Diamant <hpfcjrd!diamant@hplabs.HP.COM>
Return-Path: <hpfcjrd!diamant>
To: common-lisp@sail.stanford.edu
Subject: Proposal #13: Structure Sharing in Arguments
Subject: #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14
From: Kent M Pitman <hplabs!KMP@SCRC-STONY-BROOK.ARPA>
Proposal #13: Structure Sharing in Arguments
In the case of &REST in macros, I see no reason to not simply say
that the argument list is -always- shared. Is there an argument for
why this might not always be possible? In the case of &BODY, it may
not be possible to do the sharing, so I'm willing to leave this
undefined and say it "is an error" to modify the list.
A language specification has no business specifying implementation details.
Requiring that the list be shared is an efficiency requirement, not a
language specification. I agree with the warning that the list may be
shared, but I certainly wouldn't require it!
John
∂01-Aug-86 0536 DCP@ELEPHANT-BUTTE.SCRC.Symbolics.COM Proposal #9: Fast testing in PROGV
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 1 Aug 86 05:36:48 PDT
Received: from CREEPER.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54637; Fri 1-Aug-86 08:36:16 EDT
Date: Fri, 1 Aug 86 08:36 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #9: Fast testing in PROGV
To: Dan Hoey <hoey@NRL-AIC.ARPA>, jbarnett@NRTC.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: <8607312211.AA13507@nrl-aic>
Message-ID: <860801083615.2.DCP@CREEPER.SCRC.Symbolics.COM>
Date: Thu, 31 Jul 86 18:11:20 edt
From: Dan Hoey <hoey@nrl-aic>
From: Jeff Barnett <jbarnett@nrtc>
It was assumed in this and a previous message that looking for
duplicate names in the variable-list argument of a PROGV is an
N**2 operation.... It can be done in N*log N time.
You can put a mark on the property lists of the variables
for a linear algorithm.
Nit: no you can't. Putting a mark on a property list takes linear time
(length of the property list to see if it is already there), and you
have to do this for N variables. So you are back to N↑2 again, and you
are likely consing, and misusing property lists, and...
∂01-Aug-86 0955 hoey@nrl-aic Proposal #9: Fast testing in PROGV
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 1 Aug 86 09:55:22 PDT
Date: 1 Aug 1986 12:31:26 EDT (Fri)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Proposal #9: Fast testing in PROGV
To: David C. Plummer <DCP@scrc-QUABBIN.ARPA>
Cc: jbarnett@NRTC.ARPA, common-lisp@SU-AI.ARPA
Message-Id: <523297888/hoey@nrl-aic>
Date: Fri, 1 Aug 86 08:36 EDT
From: David C. Plummer <DCP@scrc-QUABBIN.arpa>
From: Dan Hoey <hoey@nrl-aic>
From: Jeff Barnett <jbarnett@nrtc>
...looking for duplicate names in the variable-list argument
of a PROGV ... can be done in N*log N time.
You can put a mark on the property lists of the variables
for a linear algorithm.
Nit: no you can't.
Antinit: Sure you can.
Putting a mark on a property list takes linear time
(length of the property list to see if it is already there)
I had in mind putting a GENSYMmed on the front of the property list and
only testing for it there. (Nit me no nits about multiple processes
until they're in CLtL.)
and you have to do this for N variables. So you are back to
N↑2 again,
Nit: That's N E(L), for L the length of a property list.
and you are likely consing,
My PROGV checker would keep all its conses for use the next time.
and misusing property lists,
I would spend the extra CONS to keep the plists legal.
and...
if there is further discussion, we can do it between ourselves. Anyone
out there who wants to write a PROGV checker should check with David or
me for the latest in variable uniqueness theory.
Dan
∂01-Aug-86 0956 gls@Think.COM Proposal #9: Fast testing in PROGV
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 1 Aug 86 09:55:41 PDT
Received: from thorlac by Godot.Think.COM via CHAOS; Fri, 1 Aug 86 12:55:36 edt
Date: Fri, 1 Aug 86 12:56 EDT
From: Guy Steele <gls@Think.COM>
Subject: Proposal #9: Fast testing in PROGV
To: DCP@QUABBIN.SCRC.Symbolics.COM, hoey@NRL-AIC.ARPA, jbarnett@NRTC.ARPA,
common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860801083615.2.DCP@CREEPER.SCRC.Symbolics.COM>
Message-Id: <860801125635.6.GLS@THORLAC.THINK.COM>
Moon: 3 days, 19 hours, 20 minutes since the last quarter of the moon.
Date: Fri, 1 Aug 86 08:36 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Putting a mark on a property list takes linear time
(length of the property list to see if it is already there), and you
have to do this for N variables. So you are back to N↑2 again, and you
are likely consing, and misusing property lists, and...
Barf! Who says you have to search the entire property list? One of the
reasons we are having such an explosion of mail is that many people are
failing to think for more than three seconds before shooting from the hip.
(defun does-a-list-of-symbols-contain-duplicates-p (symbols)
(let ((unique (list 'foo)))
(unwind-protect
(dolist (s symbols)
(when (eq (car (symbol-plist s)) unique)
(return-from does-a-list-of-symbols-contain-duplicates-p t))
(setf (symbol-plist s) (list* unique t (symbol-plist s))))
(dolist (s symbols)
(if (eq (car (symbol-plist s)) unique)
(setf (symbol-plist s) (cddr (symbol-plist s)))
(return))))
nil))
Looks like linear time to me. (Historical note: the implementation of
SUBLIS in MacLisp used to pull a similar trick.)
--Guy
∂01-Aug-86 1533 Hadden.CSCES@HI-MULTICS.ARPA Re: Proposal #9 Status: Variable Name Conflicts
Received: from HI-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 1 Aug 86 15:32:44 PDT
Acknowledge-To: Hadden@HI-MULTICS.ARPA
Date: Fri, 1 Aug 86 09:46 CDT
From: Hadden@HI-MULTICS.ARPA
Subject: Re: Proposal #9 Status: Variable Name Conflicts
To: Jeff Barnett <jbarnett@NRTC.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 30 Jul 86 15:55 CDT from "Jeff Barnett"
Message-ID: <860801144651.291022@HI-MULTICS.ARPA>
actually, i think it can be done in order N. the idea is to scan down
the list checking each symbol's property list for a flag. if it's not
there, put it there; if it is, you've already seen it. the following
(untested) code may give you the idea:
(defun dup-p (arg-list)
(do ((l arg-list (cdr l))
(foo (gensym)))
((null l) (mapc #'(lambda (x) (remprop x foo)) arg-list) nil)
(if (get (car l) foo)
(progn (mapc #'(lambda (x) (remprop x foo)) arg-list)
(return t))
(setf (get (car l) foo) t))))
-geo
∂04-Aug-86 1300 Dan@Think.COM ignore this message
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 4 Aug 86 12:59:56 PDT
Received: from epicurus by Godot.Think.COM via CHAOS; Mon, 4 Aug 86 16:00:15 edt
Date: Mon, 4 Aug 86 16:00 EDT
From: Dan Aronson <Dan@Think.COM>
Subject: ignore this message
To: common-lisp@SU-AI.ARPA
Message-Id: <860804160059.2.DAN@EPICURUS.THINK.COM>
Please ignore this test of our local mailing list.
--dan
∂05-Aug-86 0908 pyramid!bein@hplabs.HP.COM synonym streams..
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 5 Aug 86 09:08:39 PDT
Received: by hplabs.HP.COM ; Tue, 5 Aug 86 09:07:35 pdt
Received: by pyramid (5.51/3.14)
id AA16356; Tue, 5 Aug 86 09:06:34 PDT
Date: 5 Aug 1986 09:05-PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: synonym streams..
To: common-lisp@su-ai
Message-Id: <523641937/bein@pyramid>
Should a close on a synonym-stream merely close what it is
synonymous with or should it too be rendered useless
after the close (regardless of what happens to the underlying
stream -- see my last note re: standard streams) ??
--David
∂05-Aug-86 1111 Masinter.pa@Xerox.COM Re: synonym streams..
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Aug 86 11:11:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 AUG 86 11:10:34 PDT
Date: 5 Aug 86 11:09 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: synonym streams..
In-reply-to: David Bein <pyramid!bein@hplabs.HP.COM>'s message of 5 Aug
86 09:05 PDT
To: common-lisp@su-ai.ARPA
Message-ID: <860805-111034-2460@Xerox>
I propose the following rule: "It is an error to attempt to close a
stream that wasn't created with open."
With this rule, it would follow that, since synonym, broadcast and
two-way streams are not created with open, it is an error to perform
"close" on them.
∂06-Aug-86 1100 @QUABBIN.SCRC.Symbolics.COM,@DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM DPB, DPBS, something like that
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 86 11:00:05 PDT
Received: from DIAMOND.S4CC.Symbolics.COM (DIAMOND.S4CC.Symbolics.COM) by QUABBIN.SCRC.Symbolics.COM via INTERNET with SMTP id 28119; 6 Aug 86 13:56:55 EDT
Received: from FIREBIRD.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 2592; Wed 6-Aug-86 10:32:11 EDT
Date: Wed, 6 Aug 86 10:31 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: DPB, DPBS, something like that
To: common-lisp@SU-AI.ARPA
Message-ID: <860806103157.4.DCP@FIREBIRD.S4CC.Symbolics.COM>
When writing system code especially, but sometimes when writing normal
code, I have often had to write long chains of DPBs, such as
(dpb val1 spec1
(dpb val2 spec2
(dpb val3 spec3
...)))
This (a) gets tedious and (b) looks bad. I would either like to extend
DPB to take an odd number of arguments, or have a new function which
does. (It probably wants to be a function rather than a macro.) Thus,
(dpb val1 spec1
val2 spec2
val3 spec3
...
background-integer)
Have others had a need for this and would find this generally useful?
∂06-Aug-86 1724 @QUABBIN.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM Re: synonym streams..
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 86 17:24:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM (EUPHRATES.SCRC.Symbolics.COM) by QUABBIN.SCRC.Symbolics.COM via INTERNET with SMTP id 28297; 6 Aug 86 20:22:51 EDT
Date: Wed, 6 Aug 86 20:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: synonym streams..
To: common-lisp@SU-AI.ARPA
In-Reply-To: <860805-111034-2460@Xerox>
Message-ID: <860806202341.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 5 Aug 86 11:09 PDT
From: Masinter.pa@Xerox.COM
I propose the following rule: "It is an error to attempt to close a
stream that wasn't created with open."
With this rule, it would follow that, since synonym, broadcast and
two-way streams are not created with open, it is an error to perform
"close" on them.
I think this is a fine suggestion.
∂06-Aug-86 1904 SOLEY@XX.LCS.MIT.EDU DPB, DPBS, something like that
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 86 19:04:28 PDT
Date: Wed, 6 Aug 1986 22:09 EDT
Message-ID: <SOLEY.12228779029.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: DPB, DPBS, something like that
In-reply-to: Msg of 6 Aug 1986 10:31-EDT from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
Date: Wednesday, 6 August 1986 10:31-EDT
From: David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
To: common-lisp at SU-AI.ARPA
Re: DPB, DPBS, something like that
(dpb val1 spec1 (dpb val2 spec2 (dpb val3 spec3 ... int)))
==>
(dpb val1 spec1 val2 spec2 val3 spec3 ... int)
Have others had a need for this and would find this generally useful?
I too have written this a million times. It's an obvious
upward-compatible extension.
∂09-Aug-86 2041 mips!earl@glacier.stanford.edu :allow-other-keys query
Received: from GLACIER.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 86 20:41:09 PDT
Received: by glacier.stanford.edu with Sendmail; Sat, 9 Aug 86 20:42:42 pdt
Received: from pachyderm.UUCP (pachyderm.ARPA) by mips.UUCP (4.12/4.7)
id AA12969; Sat, 9 Aug 86 19:30:22 pdt
Received: by pachyderm.UUCP (4.12/4.7)
id AA13610; Sat, 9 Aug 86 19:30:20 pdt
Date: Sat, 9 Aug 86 19:30:20 pdt
From: mips!earl@glacier.stanford.edu (Earl Killian)
Message-Id: <8608100230.AA13610@pachyderm.UUCP>
To: common-lisp@su-ai.ARPA
Subject: :allow-other-keys query
Given
(defun bah (&key humbug)
...)
which of the following are legal?
1 (bah :allow-other-keys nil :other 'blah)
2 (bah :allow-other-keys t :other 'blah)
3 (bah :allow-other-keys nil)
Certainly 1 is in error and 2 is legal. What about 3? The way I read
the manual this is an error, which I don't think is the intent of this
feature. Opinions?
∂09-Aug-86 2104 FAHLMAN@C.CS.CMU.EDU :allow-other-keys query
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 86 21:04:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 Aug 86 00:04:09-EDT
Date: Sun, 10 Aug 1986 00:04 EDT
Message-ID: <FAHLMAN.12229586322.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: mips!earl@λglacier.stanford.edu (Earl Killian)λ
Cc: common-lisp@SU-AI.ARPA
Subject: :allow-other-keys query
In-reply-to: Msg of 9 Aug 1986 22:30-EDT from mips!earl at glacier.stanford.edu (Earl Killian)
Given
(defun bah (&key humbug)
...)
which of the following are legal?
1 (bah :allow-other-keys nil :other 'blah)
2 (bah :allow-other-keys t :other 'blah)
3 (bah :allow-other-keys nil)
Certainly 1 is in error and 2 is legal. What about 3? The way I read
the manual this is an error, which I don't think is the intent of this
feature. Opinions?
I agree with your analysis: a strict reading of the current wording of
the manual would suggest that case 3 is an error, but it would make more
sense if this were not treated as an error.
∂09-Aug-86 2320 Hvatum.DLAB@MIT-MULTICS.ARPA &rest destruction
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 9 Aug 86 23:20:36 PDT
Date: Sun, 10 Aug 86 02:11 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: &rest destruction
To: common-lisp@SU-AI.ARPA
Message-ID: <860810061145.560694@MIT-MULTICS.ARPA>
From: Steve Bacher (CSDL)
Subject: What's all this fuss about &rest destruction?
Having been watching while just about everyone on the CL mailing list
has argued about the &REST proposal, I have to jump in and make a point.
Many of you are now contending that there is no difference between
restricting the user from destroying a list passed as an argument to a
function and restricting the user from passing same list back as a
return value or storing it in "stable" storage (e.g. SETQ'ing some
global variable thereto). I find it incredible that this idea should
be suddenly gaining concurrency.
Ever since LISP began (I realize this is a meaningless argument to most
Common LISPers)... or maybe I should say that scattered throughout
every LISP manual and certainly CLtL (though I can't quote any exact
references), it has been emphasized that the destructive operations
are DANGEROUS and should be used WITH CAUTION only by EXPERIENCED
LISP PROGRAMMERS. It follows that if you are about to do something
that will destructively update a list, you'd better be damned sure
that nobody else is pointing to that list. The only way to be certain
of this is (usually) if you create the list yourself out of fresh
conses (or if you get the list back from a function which you know has
created a list safe for destruction).
Conversely, I find it hard to accept the notion that Common LISP may
specify that some particular kind of argument to a function is
GUARANTEED to be freshly consed and therefore destructible. Suppose you
have a function like
(defun foo (a b &rest c) ...)
Why should I be guaranteed that the value bound to c will be
clobberable, when I am not given such a guarantee for a and b?
Perhaps your answer will be that functions should always do COPY-LIST on
any list arguments they pass to other functions, since those other
functions might wish to do NCONC or RPLACA on their args? :-)
On the other hand, NEVER in the history of any LISP that I know has
there been a rule that for some situation or other, the user may not
pass a given object back as a return value or store it somewhere
permanent. Such a restriction is truly abhorrent and contrary to the
spirit of the language. But it sure might make some compiler
implementors happy. Imagine: the whole problem of upward funargs
could have been avoided so easily - just tell users that functions
may be passed as arguments, but they may not be returned as values or
assigned to global variables! We might never had had to design all
those hairy mechanisms for saving environments in heap storage.
If the rationale behind this is that certain implementations
put their &REST args on the stack to save some conses, that's just too
bad. (Should we support implementations that keep lexical closure
environments on the stack because it's just too hard to let users
pass lexical closures around as arguments?) I agree with
Scott Fahlman's suggestion for an additional mechanism in the
language to provide for LEXPR'ish passing of varying numbers of args
on the stack as an alternative to consing &REST lists.
In short, there most definitely IS a qualitative distinction between
proscribing wanton clobbering of lists regardless of their origin
and limiting users' right to do with arguments what they please in
nondestructive ways.
- Steve Bacher
C.S.Draper Laboratory
≠
∂10-Aug-86 1205 FAHLMAN@C.CS.CMU.EDU &rest destruction
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 86 12:05:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 Aug 86 15:05:34-EDT
Date: Sun, 10 Aug 1986 15:05 EDT
Message-ID: <FAHLMAN.12229750419.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: &rest destruction
In-reply-to: Msg of 10 Aug 1986 02:11-EDT from Hvatum at MIT-MULTICS.ARPA
From: Steve Bacher (CSDL)
Subject: What's all this fuss about &rest destruction?
...
Conversely, I find it hard to accept the notion that Common LISP may
specify that some particular kind of argument to a function is
GUARANTEED to be freshly consed and therefore destructible. Suppose you
have a function like
(defun foo (a b &rest c) ...)
Why should I be guaranteed that the value bound to c will be
clobberable, when I am not given such a guarantee for a and b?
The situation for A and B is not the same as for C. The values for A
and B come direct from the caller. In the case of a normal call to FOO,
the value passed in for C will be a list that is freshly consed at
runtime. The only case in which C might not be freshly consed is if FOO
is called via APPLY. Since calls via APPLY are relatively rare, the
question is whether we should require copying in this rare case (which
would allow users to assume that a rest arg is ALWAYS freshly-consed),
or whether we should warn the users that the &rest arg may have shared
top-level strucutre in some rare cases.
The issue of whether &rest args have indefinite extent is a separate
one, dragged in by some random comments by DCP. It seems that everyone
agrees that Common Lisp currently requires &rest args to have indefinite
extent, and that this should not be changed.
-- Scott
∂10-Aug-86 1350 shebs%utah-orion@utah-cs.arpa TAGBODY vs LABELS
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 10 Aug 86 13:50:10 PDT
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA23843; Sun, 10 Aug 86 14:50:42 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA00254; Sun, 10 Aug 86 14:50:39 MDT
Date: Sun, 10 Aug 86 14:50:39 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
Message-Id: <8608102050.AA00254@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: TAGBODY vs LABELS
I was in the process of implementing TAGBODY in terms of LABELS (each
piece of straightline code turns into a function, and GO turns into
function calls), but upon perusing CLtl more closely, I found that
the GO is apparently supposed to undo catchers, which wouldn't happen
if it becomes a function call... Is this analysis correct? If so,
then perhaps the standard deserves something a little stronger than
the phrase "can break up catchers if necessary to get to the target"
(middle of p. 131), which leaves me wondering what else GOs are supposed
to do to get to those elusive targets...
stan
∂10-Aug-86 2132 RAM@C.CS.CMU.EDU TAGBODY vs LABELS
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 86 21:32:09 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 11 Aug 86 00:32:27-EDT
Date: Mon, 11 Aug 1986 00:32 EDT
Message-ID: <RAM.12229853616.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: shebs%utah-orion@λutah-cs.arpa (Stanley Shebs)λ
Cc: common-lisp@SU-AI.ARPA
Subject: TAGBODY vs LABELS
In-reply-to: Msg of 10 Aug 1986 16:50-EDT from shebs%utah-orion at utah-cs.arpa (Stanley Shebs)
GO has to do whatever is necessary in your implementation to get
out of whatever possible stuff that you wrap around the GO. There are
no restrictions on where a GO may appear other than that it must
be lexically within the body of the TAGBODY and that it must be
evaluated within the dynamic context of the TAGBODY.
It may be partly due to a lack of complete understanding of how
the LABELS hack works, but I believe that there isn't a
straightforward general conversion in Common Lisp. In general, any
kind of dynamic state may have to be magically undone. Consider the
example in p131 where the call to MAPCAR is aborted by a GO. Special
bindings seem to cause similar problems.
Rob
∂10-Aug-86 2327 masinter.PA@Xerox.COM tagbody using labels
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Aug 86 23:27:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 10 AUG 86 23:27:33 PDT
From: masinter.PA@Xerox.COM
Date: 10 Aug 86 23:26:24 PDT
Subject: tagbody using labels
To: ram@c.cs.cmu.edu
cc: common-lisp@su-ai.ARPA
Message-ID: <860810-232733-1239@Xerox>
GO requires no more magic than return-from.
This was an interesting puzzle. This definition doesn't handle go's from
inside an inner tagbody to an outer one, but I couldn't figure out how
to do that without introducing a compiler-let.
(defmacro tagbody (&rest rest)
(labels
((parse (tail &aux (rest (member-if #'atom (cdr tail))))
(if tail (cons (cons (gensym) (ldiff tail rest)) (parse rest)))))
(let ((name (gensym))
(bodies (parse (cons (gensym) rest))))
`(block ,name
(macrolet ((go (tag)
`(return-from ,(car (find tag ',bodies :key 'cadr))
nil)))
(labels
,(maplist
#'(lambda (tail)
`(,(caar tail) ()
,@(reduce #'(lambda (body tag)
`((block ,(car tag) ,@body)
(return-from ,name (,(car tag)))))
bodies
:initial-value
`(,@(cddar tail)
,(if (cdr tail)
`(return-from ,(caadr tail) nil))))))
bodies)
(,(caar bodies))))))))
Larry
<:-)
∂11-Aug-86 0916 gls@Think.COM ,',@
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Aug 86 09:16:06 PDT
Received: from nymphodora by Godot.Think.COM via CHAOS; Mon, 11 Aug 86 12:15:53 edt
Date: Mon, 11 Aug 86 12:16 EDT
From: Guy Steele <gls@Think.COM>
Subject: ,',@
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860801153243.3.ALAN@PIGPEN.AI.MIT.EDU>
Message-Id: <860811121629.4.GLS@NYMPHODORA.THINK.COM>
For the record, I was somewhat wedged in my last reply to Alan about
,',@ and I am now in full agreement with him on the technical issues.
--Guy
∂11-Aug-86 1120 gls@Think.COM tagbody using labels
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Aug 86 11:19:35 PDT
Received: from nymphodora by Godot.Think.COM via CHAOS; Mon, 11 Aug 86 14:19:34 edt
Date: Mon, 11 Aug 86 14:20 EDT
From: Guy Steele <gls@Think.COM>
Subject: tagbody using labels
To: common-lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <860810-232733-1239@Xerox>
Message-Id: <860811142008.3.GLS@NYMPHODORA.THINK.COM>
Utterly astonishing! --Guy
∂11-Aug-86 2258 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM TAGBODY vs LABELS
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 11 Aug 86 22:57:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 61106; Tue 12-Aug-86 01:56:40 EDT
Date: Tue, 12 Aug 86 01:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: TAGBODY vs LABELS
To: Stanley Shebs <shebs%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8608102050.AA00254@utah-orion.ARPA>
Message-ID: <860812015648.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 10 Aug 86 14:50:39 MDT
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)
I was in the process of implementing TAGBODY in terms of LABELS (each
piece of straightline code turns into a function, and GO turns into
function calls), but upon perusing CLtl more closely, I found that
the GO is apparently supposed to undo catchers, which wouldn't happen
if it becomes a function call... Is this analysis correct? If so,
then perhaps the standard deserves something a little stronger than
the phrase "can break up catchers if necessary to get to the target"
(middle of p. 131), which leaves me wondering what else GOs are supposed
to do to get to those elusive targets...
Most people implement non-local GO in terms of THROW and local GO.
(tagbody (foo #'(lambda () (go a)))
(baz)
a (bar))
==>
(tagbody (case (catch g0001
(foo #'(lambda () (throw g0001 1)))
2)
(1 (go a))
(2 (baz)))
a (bar))
or
(tagbody (catch g0001
(foo #'(lambda () (throw g0001 nil)))
(go g0002))
(go a)
g0002 (baz)
a (bar))
where g0001 is bound to something dynamically unique (using
a gensym constant here won't work, you should easily be able
to construct a counterexample using recursive functions).
Regardless of your exact implementation, I think you'll find that cases
exist in which only an implementation of GO that uses THROW will work.
∂11-Aug-86 2307 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM :allow-other-keys query
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 11 Aug 86 23:07:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 61108; Tue 12-Aug-86 02:05:59 EDT
Date: Tue, 12 Aug 86 02:06 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :allow-other-keys query
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12229586322.BABYL@C.CS.CMU.EDU>
Message-ID: <860812020607.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 10 Aug 1986 00:04 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
From: earl
Given
(defun bah (&key humbug)
...)
which of the following are legal?
1 (bah :allow-other-keys nil :other 'blah)
2 (bah :allow-other-keys t :other 'blah)
3 (bah :allow-other-keys nil)
Certainly 1 is in error and 2 is legal. What about 3? The way I read
the manual this is an error, which I don't think is the intent of this
feature. Opinions?
I agree with your analysis: a strict reading of the current wording of
the manual would suggest that case 3 is an error, but it would make more
sense if this were not treated as an error.
Our implementation treated 3 as an error for a while, due to being misled
by the manual, and we decided that that was a bug. I agree with Earl;
all &key functions accept :allow-other-keys, and the manual (pp.62-3)
should be clarified accordingly.
∂12-Aug-86 1246 snyder%hplsny@hplabs.HP.COM Re: Proposal #7 Status: TYPE-SPECIFIER-P
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 12 Aug 86 12:46:07 PDT
Received: from hplsny by hplabs.HP.COM ; Tue, 12 Aug 86 12:45:21 pdt
Received: by hplsny ; Tue, 12 Aug 86 12:44:44 pdt
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
Message-Id: <8608121944.AA12075@hplsny>
Date: Tue, 12 Aug 86 12:43:53 PDT
Subject: Re: Proposal #7 Status: TYPE-SPECIFIER-P
To: Masinter.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: common-lisp@su-ai.ARPA
In-Reply-To: Your message of 28-Jul-86 11:52:00
X-Mailer: NMail [$Revision: 2.5 $]
Date: 28 Jul 86 11:52 PDT
From: Masinter.pa@Xerox.COM
c) this is a request for a feature, but there's little evidence that
there are significant, meaningful, portable uses for it. (Portable = a
program written with one Common Lisp's version is likely to run with
another Common Lisp's version.)
e) there is another proposal (before the Object Oriented Programming
committee in this case) which satisfies at least part of the original
requirement in a different way.
Date: Mon, 28 Jul 86 20:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I have no objection to either of TYPE-SPECIFIER-P or TYPE-NAME-P if
someone can show why these are needed to fix something wrong with the
language. Perhaps Guy can comment on why the original proposal 51 in
his clarifications list was tagged with an asterisk indicating that it
corrects an important flaw or resolves an ambiguity in the
specification.
I think the original request for this feature came from me, and the motivation
was in fact to allow the portable implementation of object-oriented
programming extensions. If DEFCLASS defines a TYPE, then DEFCLASS needs some
way to tell if the specified class name is the name of an existing type, so
that it can issue some reasonable error message. (Presumably, DEFCLASS knows
if the specified name is the name of an existing CLASS, but it doesn't know
about other types.) TYPE-NAME-P is adequate for this purpose, although it
would look ugly to have TYPE-NAME-P in the language if we ever figured out
what TYPE-SPECIFIER-P should do (perhaps Guy's definition is adequate).
To the best of my knowledge, neither DEFTYPE nor DEFSTRUCT define what happens
if the specified type name names an existing type. Defining their behavior in
this case might also solve the problem (if an error is signalled in all cases
of interest). (Only the moderator is allowed to interpret this paragraph as
opening a new issue!)
Alan
-------
∂13-Aug-86 1051 Moon@QUABBIN.SCRC.Symbolics.COM Proposal #7: TYPE-SPECIFIER-P
Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 13 Aug 86 10:51:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29452; Wed 13-Aug-86 13:40:34 EDT
Date: Wed, 13 Aug 86 13:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Proposal #7: TYPE-SPECIFIER-P
To: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8608121944.AA12075@hplsny>
Message-ID: <860813134107.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 12 Aug 86 12:43:53 PDT
From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
I think the original request for this feature came from me, and the motivation
was in fact to allow the portable implementation of object-oriented
programming extensions. If DEFCLASS defines a TYPE, then DEFCLASS needs some
way to tell if the specified class name is the name of an existing type, so
that it can issue some reasonable error message. (Presumably, DEFCLASS knows
if the specified name is the name of an existing CLASS, but it doesn't know
about other types.) TYPE-NAME-P is adequate for this purpose, although it
would look ugly to have TYPE-NAME-P in the language if we ever figured out
what TYPE-SPECIFIER-P should do (perhaps Guy's definition is adequate).
To the best of my knowledge, neither DEFTYPE nor DEFSTRUCT define what happens
if the specified type name names an existing type. Defining their behavior in
this case might also solve the problem (if an error is signalled in all cases
of interest). (Only the moderator is allowed to interpret this paragraph as
opening a new issue!)
I see. Note that you should be allowed to re-evaluate "the same" DEFTYPE,
DEFSTRUCT, or DEFCLASS, but should get an error if you evaluate one that is
not "the same" but has the same name. This seems like a programming
environment issue. For example, in Symbolics' system "the same" is defined by
the name of the file containing the form, with all forms typed in from the
terminal assumed to be "the same" and not "the same as" any form that came
from a file. I can easily imagine other programming environments where
"the same" would be defined in a very different way.
The problem with calling this a programming environment issue rather than a
language issue is that that doesn't make it go away, since the whole point was
that you want a portable way to define (or extend) the programming
environment. I don't have any solutions to offer, but my opinion is that
one of TYPE-NAME-P or TYPE-SPECIFIER-P should exist, but DEFCLASS should not
need to call it.
∂13-Aug-86 2151 LOOSEMORE@UTAH-20.ARPA question about subtypep
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 13 Aug 86 21:43:17 PDT
Date: Wed 13 Aug 86 22:43:11-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: question about subtypep
To: common-lisp@SU-AI.ARPA
Message-ID: <12230642017.7.LOOSEMORE@UTAH-20.ARPA>
On p. 35 of CLtL, it says that the type "array" may or may not be a
subtype of "common", depending on whether your implementation allows you
to make arrays that can only hold items of a type which isn't a subtype
of common. Supposing the implementation has not made this extension, is
it acceptable for (subtypep 'array 'common) to return T? Or is subtypep
only supposed to return T if the subtype relationship definitely holds
in *all* CL implementations?
-Sandra
-------
∂14-Aug-86 0353 RAM@C.CS.CMU.EDU question about subtypep
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86 03:52:59 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 14 Aug 86 06:51:55-EDT
Date: Thu, 14 Aug 1986 06:51 EDT
Message-ID: <RAM.12230709127.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: question about subtypep
In-reply-to: Msg of 14 Aug 1986 00:43-EDT from SANDRA <LOOSEMORE at UTAH-20.ARPA>
CLTL is pretty vague about what subtypep does. My intpretation
(based on intensive meditation and reading of scripture) is that
SUBTYPEP returns information about the actual subtype relations in
your implementation. Discrepencies will exist most often when an
implementation decides to fold potentially distinct types together.
For example, if all arrays are adjustable and have fill-pointers, then
SIMPLE-ARRAY is indentical to ARRAY, and therefore
(SUBTYPEP 'ARRAY 'SIMPLE-ARRAY) is true.
Note there are some possible users of SUBTYPEP that would prefer
answers to be based on some hypothetical maximally restrictive type
system. The main example is a compiler which does compile-time type
checking when possible. Although (THE SHORT-FLOAT 1F0) is quite legal
in an implementation in which SHORT-FLOAT and SINGLE-FLOAT are
identical, it would be reasonable for the compiler to give a warning
anyway. Applications that care about this sort of thing will have to
use a variant version of subtypep that is distinct from the real
SUBTYPEP.
Rob
∂14-Aug-86 0559 Hvatum.DLAB@MIT-MULTICS.ARPA &rest destruction
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 14 Aug 86 05:59:37 PDT
Date: Thu, 14 Aug 86 08:57 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: &rest destruction
To: common-lisp@SU-AI.ARPA
Message-ID: <860814125727.259238@MIT-MULTICS.ARPA>
From: Steve Bacher: CSDL
Subject: &rest destruction
I see one more potential case where the &rest args may be indestructible - a
possible compiler optimization where, given a function
(defun foo (&rest x) ...)
and a call like
(foo 'bar 'baz 'frob)
the compiler may choose to pass an inline list '(BAR BAZ FROB) to save
on consing. Guaranteed destructibility would merely enjoin the compiler
writer from generating this optimization, which would probably not be a
problem (although I wouldn't be too happy with such a restriction).
(There's one other useful case: if there's a function FROBOZZ,
say, that takes one &REST arg, the compiler should be able to take
(apply #'frobozz some-list)
and compile it as a direct call to FROBOZZ, passing the list itself on
as is. In some architectures this may be much more efficient, even
apart from the elimination of APPLY from the picture; there may be
an INTERNAL-FROBOZZ that takes a single list arg and does the same
thing, in which case the compiler could do a source transform on the
above. Again, forced consing in this (possibly more frequent) case
could be detrimental.)
- Steve
≠
∂14-Aug-86 1444 Pavel.pa@Xerox.COM More words on the scoping of declarations
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Aug 86 14:43:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 AUG 86 14:11:51 PDT
Date: 14 Aug 86 14:11 PDT
From: Pavel.pa@Xerox.COM
Subject: More words on the scoping of declarations
In-reply-to: NGALL@G.BBN.COM's message of 19 Jul 86 17:17 EDT
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860814-141151-4806@Xerox>
Having been gone for three weeks, I was unable to properly defend my
proposal on the scoping of declarations. Although I've been back for
three days now, I have only now finished reading the incredible torrent
of mail spewed out over that time. I therefore ask for your indulgence
as I refer to messages now more than 25 days old. I have included
contextual excerpts for those of you who haven't just read it all at
once.
Date: 19 Jul 86 17:17 EDT
From: NGALL@G.BBN.COM
Date: 11 Jul 86 18:43 PDT
From: Pavel.pa@Xerox.COM
In this message I will give a complete description of my proposal
for
declaration scoping. I won't attempt to argue for it on the basis
of
``obviousness'' or clarity, though, because I think that there are
people who find each of the two ways of scoping special
declarations
confusing. Rather, I like this way of doing things because it
satisfies
an important (to me) consistency criterion: the scope of \any/
declaration coincides with a particular lexical identifier scope.
I don't think you mean 'any' here; I think you mean 'any declaration
that concerns the bindings of variables' (cf. pg. 154). You cannot
mean 'any' since in the example below
(let ((x 1))
(declare (inline foo))
(foo x))
the declaration does not 'coincide with a particular lexical
identifier scope.' A more extreme example is
(let (...)
(declare (optimize ...))
...)
in which the declaration does not refer to ANY named entity.
Being a disciple of the Mad Hatter, I said what I meant and meant what I
said. A declaration need not refer to a named entity in order to share
that entity's scope. In the second example you gave, the OPTIMIZE
declaration applies to the bindings made in the LET and to all code in
the body of the LET. Thus, if we were asking to optimize speed at the
expense of space, the compiler would be encouraged to bind the variables
in the fastest way possible, even if it used up an extra stack cell, for
example. I fully understand that most implementations, including that
of Xerox, haven't the freedom to further optimize the creation of
bindings (though it is a fascinating concept...). The point is that
those bindings \are/ covered by the declaration and that the init-forms
for the bindings are \not/ so covered, as stated in my proposal.
Unfortunately, TYPE and IGNORE are the only decl specs that only
concern bindings. SPECIAL concerns bindings also, but it
also pervasively affects references (this is what you want changed).
I am \not/ trying to change the so-called ``pervasive'' nature of
special declarations, only their scope. More on this later.
And FTYPE and INLINE simply confuse me.
How can FTYPE be confusing when TYPE is not? They perform precisely
symmetrically along the value/function axis. TYPE makes a statement
about the kinds of \values/ that can be referred to by the \value/-names
given, while FTPYPE makes a statement about the kinds of \functions/
that can be referred to by the \function/-names given. No difference,
no confusion.
First of all, FTYPE is not explicitly stated to be a pervasive decl
spec, I believe this is an omission. Secondly, there is this
confusing sentence at the end of their descriptions:
"Note that the rules of lexical scoping are observed; if one of the
functions mentioned has a lexically apparent local definition (as made
by FLET or LABELS), then the declaration applies to that local
definition and not to the global definition."
This makes it sound like FTYPE and INLINE are like SPECIAL: they
concern bindings AND affect references (but not pervasively?).
For example,
(FLET ((zap (...)...(zap...)...))
(declare (inline zap))
...)
Is the call to zap in the local definition of zap affected by the
declaration? My reading of CLtL and commonsense make me answer no.
The call to zap is not a call to the local def. of zap, and according
to my reading of the sentence quoted above, the decl. only affects
references within the scope of the innermost binding of the name zap.
But this interpretation depends upon not interpreting 'pervasively' as
stated in CLtL. Is my interpretation correct?
One is strongly reminded of rabbinical study of the Talmud...
This whole view of pervasive vs. non-pervasive is a red herring based
upon some unclearly-written prose in CLtL. A given declaration has a
certain scope and has an effect (possibly empty) on every single
language construct in that scope. Thus, \every/ declaration is
``pervasive'' in the sense of CLtL. To describe the meaning of a given
kind of declaration, it is necessary and sufficient to lay out its
effect on every kind of language feature that can appear within its
scope; clearly, most declaration-kinds will have non-empty effects on
only a small set of language features. For example, a SPECIAL
declaration affects variable bindings and references, but not
function-calls or other declarations. The DECLARATION declaration
affects only other declarations and none of variable bindings,
references or function calls. I will lay out my understanding of the
meanings of all of the CLtL declaration-kinds in another message (since
this one is going to be too long as it is).
I propose the following change to CLtL (which pretty much agrees with
both CLtL and Pavel):
...
I disagree with the statement that Nick's proposal agrees with mine.
...
Some examples should help clarify this:
(let ((y x))
(declare (type list x))
...x...)
Both references to x are affected.
(let ((x x))
(declare (type list x))
...x...)
Only the second reference to x is affected (since the first reference
is not within the scope of the binding named by x).
This is losing. Either the init-forms of the LET should be covered by
the declarations or they should not, but it shouldn't depend upon what
variables are being bound. It is precisely behaviour like this against
which I am raging: the scope of declarations corresponding to random,
arbitrary, and hard-to-remember rules as opposed to the same, sane rules
of lexical scoping around which the whole remainder of the language
revolves.
(FLET ((zap (...)...(zap...)...(zoop...)...))
(declare (function zap (...)...)
(function zoop (...)...))
...)
The call to zap is not affected, but the call to zoop is.
This is the example that really hurts. The world will be a simpler
place if we can simply agree that every declaration has a certain scope,
regardless of what constructs appear in that scope. Thus, the scope of
these declarations either includes or does not include the body of the
function ZAP. If they do (and I think that they should not), then both
function calls shown should be affected. If the scope does not include
that body, then neither call is affected. Clear?
Note that I specified a \single/ scope for both declarations above, not
a separate one for each; the only exception to this policy should be the
sequential binding forms, including LAMBDA.
I believe this proposal is complete, consistent, and simple to apply.
I believe this proposal is incomplete (since it does not include a
specific enumeration of the semantics of all declarations in all of the
special forms), inconsistent (see my last set of comments above) and
difficult to apply (it requires examination of the names of variables
being bound, as opposed to having scope and semantics independent of
specific context).
-----------
The next proposal was from Bawden and was later dubbed ``Bawden's
Alternate Proposal'':
Date: Mon, 21 Jul 86 16:02:37 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
...
Actually, the more I think about this as a simplification, the more I
like
it. So here is a counter-proposal for rationalizing the semantics of
declarations:
1. All declarations are completely pervasive. That is, if you write
(locally (declare (special foo)) ...)
then every occurance of FOO within the body is taken to be a special
reference or a special binding. The only way to escape from the
effects of
a declaration within the body, is to explicitly shadow the declaration
with
another. This applies to -all- declarations: FTYPE, INLINE, etc.
2. Declarations that occur in the bodies of special forms (DEFUN, LET,
DO,
etc.), and in LAMBDA expressions, are taken to mean the same thing as
if
the entire form was enclosed in a LOCALLY containing the same
declarations.
So
(let ,pairs ,@dcls ,@body)
and
(locally ,@dcls (let ,pairs ,@body))
are completely equivalent.
(Since LAMBDA expressions aren't forms, the equivalent using LOCALLY
isn't
always completely straightforward to construct. For example, this
case:
((lambda ,vars ,@dcls ,@body) ,@vals)
is equivalent to using LOCALLY as follows:
(funcall (locally ,@dcls (function (lambda ,vars ,@body))) ,@vals)
.)
One certainly can't fault this proposal on the ground of complexity.
No, my major objection to Alan's plan is that it sets up an entirely
separate scoping mechanism for declarations. That mechanism is entirely
lexical and straightforward and all that, but it's not the same one that
the binding of names uses. Why have two scopes when one will do? Also,
I agree with Paul the Greek that the following is undesirable:
Date: Mon, 21 Jul 86 17:55:05 EDT
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
From: "BACH::GREEK" <greek%bach.decnet@hudson.dec.com>
Bawden's proposal would result in the following.
(FLET ((FOO (X) (FOO X X)))
(DECLARE (FUNCTION FOO (INTEGER) INTEGER))
... (FOO 5) ...)
The declaration for FOO would pertain to both the locally-defined
FOO and the outer FOO used in its body.
This is correct. Since function names are lexically scoped, you can
call
the inner function something other than FOO with only a minor change to
your program. Is this situation actually common in anyone's code?
It bothers me that a single declaration can refer to two different
variables that happen to share the same name. Notice that it is the
creation of a separate-but-equal scoping mechanism for declarations that
causes this problem; were declarations to use the same scoping mechanism
as names, this problem could not arise.
JonL wrote in support of Alan's proposal:
Date: Wed, 23 Jul 86 03:53:30 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
...
It seems to me that Alan's proposal infuses declarations with the same
kind of scoping semantics that exists for variable bindings. In the
form
(let ((a <something>))
. . .
(let ((a <something-else>))
. . .
))
the meaning of this is "a is bound to something, unless it is bound
to something else"; which is parallel to Alan's notion for declarations
that has (unfortunately) been called "shadowing".
I find the unification of these two scoping rules to be very
attractive.
-- JonL --
Alan's proposal does not unify the two scoping rules, but rather grants
them both first-class status, separate but equal, as I said above. I
believe that my proposal, linking the scope of declarations directly to
the scope of names, truly unifies the two.
I've talked enough for this letter. I will send out a separate message
revising and completing my proposal in as much detail I would expect
(hope) the language specification to contain.
Pavel
∂14-Aug-86 1602 RAM@C.CS.CMU.EDU More words on the scoping of declarations (FTYPE)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 86 15:59:44 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 14 Aug 86 18:57:21-EDT
Date: Thu, 14 Aug 1986 18:57 EDT
Message-ID: <RAM.12230841185.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: More words on the scoping of declarations (FTYPE)
In-reply-to: Msg of 14 Aug 1986 17:11-EDT from Pavel.pa at Xerox.COM
My reading of the manual supports the claim that FTYPE is not
symmetrical with TYPE. TYPE may only be used with a binding, while
FTYPE is shown in examples as being used "pervasively" on a global
identifier. If FTYPE was in fact like TYPE, then you couldn't use it
at all, since currently no declarations are allowed in functional
binding forms.
Whether this is desirable is another point altogether. We should
probably clean up this gratuitous inconsistency if we are going to
make sweeping changes to the declaration scoping rules.
Rob
∂15-Aug-86 0734 cvfong@mitre.ARPA drop out
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 15 Aug 86 07:34:18 PDT
Full-Name: C. Vanessa Fong
Message-Id: <8608151424.AA21531@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: common-lisp@su-ai.ARPA
Subject: drop out
Date: Fri, 15 Aug 86 10:24:33 -0500
From: Vanessa Fong <cvfong@mitre.ARPA>
Please delete my name from your distribution list. Thanks!
C. Vanessa Fong (cvfong@mitre.arpa)
∂18-Aug-86 1101 RAM@C.CS.CMU.EDU More words on the scoping of declarations
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86 11:01:09 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 18 Aug 86 14:01:05-EDT
Date: Mon, 18 Aug 1986 13:56 EDT
Message-ID: <RAM.12231834939.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: More words on the scoping of declarations
In-reply-to: Msg of 14 Aug 1986 17:11-EDT from Pavel.pa at Xerox.COM
I think that I like the substance of your proposal for declaration
scoping, but I have some misgivings about the way that you have
expressed it.
In your definition, you attempt to simply define all interactions
between all forms where declarations can appear and all code that can
appear in them. This approach attempts to deny the need for a theory
of declaration scoping. Such a theory would give people a model for
understanding how things work, and would also enforce some sort of
consistency in the definition.
It is evident that you do have a theory of variable binding, but
you don't really attempt to formalize it to the point where
declartion semantics becomes obvious. You theory is based on the idea
that declaration scoping should follow the same scope rules as
variables. It is a property of this theory that a declaration for a
specific name cannot refer to multipel variables which have the same
name.
So far as the application of the theory goes, the main problem
that I see is with LET* and possibly other places where sequential
bindings happen. It is not obvious to me what the scope of
delcarations in LET* should be, even if we disallow repeated variable
names.
Rob
∂18-Aug-86 1459 @DIAMOND.S4CC.Symbolics.COM:File-Server@DIAMOND.S4CC.Symbolics.COM string-/=, etc.
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 18 Aug 86 14:58:53 PDT
Date: Mon, 18 Aug 86 17:58 EDT
From: DCP@QUABBIN.SCRC.Symbolics.COM
Sender: File-Server@DIAMOND.S4CC.Symbolics.COM
Subject: string-/=, etc.
To: common-lisp@SU-AI.ARPA
Supersedes: <860808175848.1.DCP@FIREBIRD.S4CC.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <860818175815.4.FILE-SERVER@DIAMOND.S4CC.Symbolics.COM>
Page 301 is slightly ambiguous. If you read it carefully, some parts
imply it is a relative index ("...then the result is the index within
the strings..." and "put another way, the result is the length of the
logest common prefix...") but other parts imply it is absolute ("The
index returned in case of a mistmatch is an index into /string1/.") The
last sentence on the page is the real clincher, but is said much too
late and the almost-relative wording.
[In hindsight, some of us may think the answer should be relative to the
beginning of the specified substrings, not absolute in string1, but
that's incompatible and probably too incompatible.]
∂18-Aug-86 1725 HEDRICK@RED.RUTGERS.EDU close on synonym streams, etc
Received: from RED.RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 86 17:25:40 PDT
Date: 18 Aug 86 20:25:45 EDT
From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
Subject: close on synonym streams, etc
To: common-lisp@SU-AI.ARPA
Message-ID: <12231905873.61.HEDRICK@RED.RUTGERS.EDU>
I would think that it would be legal to close a synonym stream,
broadcast stream, etc., but that this close would affect only the
synonym stream, as opposed to the stream it points to. I could conceive
of implementations where buffering is done in each stream. In that
case, it might be a good idea to close a synonym or broadcast stream, in
order to make sure that any buffered characters are taken care of and
any cleanup is done. It should be an error to do any I/O operation on a
stream that has been closed. If you intend to outlaw close on one
of these composite streams, then you should mention this fact clearly
where synonym and broadcast streams are defined, and note that this
means that they must be implemented in such a way that a close is not
required when you are finished using them.
-------
∂18-Aug-86 1825 franz!fizzy!jkf@kim.Berkeley.EDU Re: synonym streams..
Received: from [128.32.130.7] by SAIL.STANFORD.EDU with TCP; 18 Aug 86 18:25:39 PDT
Received: by kim.Berkeley.EDU (5.53/1.16)
id AA01094; Mon, 18 Aug 86 18:26:34 PDT
From: franz!fizzy!jkf@kim.Berkeley.EDU
Received: from fizzy by franz (5.5/3.14)
id AA11103; Mon, 18 Aug 86 15:22:33 PDT
Received: by fizzy (4.12/3.14)
id AA19698; Mon, 18 Aug 86 15:23:02 pdt
Return-Path: <fizzy!jkf>
Message-Id: <8608182223.AA19698@fizzy>
To: ucbkim!Xerox.COM!Masinter.pa
Cc: common-lisp@su-ai.arpa
Subject: Re: synonym streams..
In-Reply-To: Your message of 05 Aug 86 11:09:00 PDT.
<860805-111034-2460@Xerox>
Date: Mon, 18 Aug 86 15:22:59 PDT
>> Date: 5 Aug 86 11:09 PDT
>> From: franz!ucbkim!Xerox.COM!Masinter.pa
>> I propose the following rule: "It is an error to attempt to close a
>> stream that wasn't created with open."
>> With this rule, it would follow that, since synonym, broadcast and
>> two-way streams are not created with open, it is an error to perform
>> "close" on them.
[sorry for the delay in the reply, this is the first chance I've had
to reply]
This topic was brought up in this mailing list on Aug 21, 1985 and
discussed at great length on Sept 7, 1985. My feeling was then and
is still now that closing a synonym stream is legal, and that the only
effect is that read and writes to the closed synonym stream will cause an
error to be signaled. [At the time the only other possibility
discussed was that closing a synonym stream would cause the stream
that it was a synonym of to be closed as well. No one has brought
this option up so I assume that either it has no backers or else they
are on vacation].
Suppose I have a function which takes a stream and reads and
processes data from that stream and when an eof is seen, it closes the
stream and returns. What is to be gained by my program having to know
about synonym streams and having to check that it wasn't a synonym
stream passed in before it does a close? I would like my function to
be able to accept input from *standard-input* by having
my program create a synonym stream (call it X) for *standard-input*
and passing it to the function. When my function closes X, that should
be ok, and it shouldn't affect *standard-input* (or *terminal-io*,
if *standard-input* is a synonym for *terminal-io*).
-john foderaro
Franz Inc.
∂19-Aug-86 1045 ACUFF@SUMEX-AIM.ARPA Re: synonym streams..
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 86 10:45:33 PDT
Date: Tue 19 Aug 86 10:45:43-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Re: synonym streams..
To: franz!fizzy!jkf@KIM.BERKELEY.EDU,
ucbkim!Xerox.COM!Masinter.pa@KIM.BERKELEY.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8608182223.AA19698@fizzy>
Message-ID: <12232095191.66.ACUFF@SUMEX-AIM.ARPA>
I agree with John that making it an error to close an active stream
of any sort is a mistake, since the closing code may have picked up
the stream anywhere and not know its nature.
What are the arguments against CLOSE closing the actual stream passed
to it, leaving any underlying streams alone? The only one I can think
of is the desire to close those underlying streams as well, which indicates
a potential need for a mechanism to recover embedded streams.
-- Rich
-------
∂19-Aug-86 1240 KMP@STONY-BROOK.SCRC.Symbolics.COM close on synonym streams, etc
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Aug 86 12:40:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83435; Tue 19-Aug-86 15:24:50 EDT
Date: Tue, 19 Aug 86 15:24 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: close on synonym streams, etc
To: HEDRICK@RED.RUTGERS.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12231905873.61.HEDRICK@RED.RUTGERS.EDU>
Message-ID: <860819152419.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 18 Aug 86 20:25:45 EDT
From: Charles Hedrick <HEDRICK@RED.RUTGERS.EDU>
... I could conceive of implementations where buffering is done
in each stream. In that case, it might be a good idea to close
a synonym or broadcast stream, in order to make sure that any
buffered characters are taken care of and any cleanup is done.
It looks to me like this issue is adequately addressed by the presence
of FINISH-OUTPUT and FORCE-OUTPUT. Perhaps the documentation could be
clearer on that point.
... If you intend to outlaw close on one of these composite streams,
then you should mention this fact clearly where synonym and broadcast
streams are defined, and note that this means that they must be
implemented in such a way that a close is not required when you are
finished using them.
Indeed, the documentation should be clear about these points.
It seems to me, however, that the only point to CLOSE is that it
allows the freeing of things like operating system "channels"
which are often critical resources. In that respect, it's like
a fast GC. If they weren't critical resources, I assume we'd
just drop pointers to streams and let the GC take care of
straightening out the resources in its own sweet time.
Since echo and broadcast streams are presumably just lisp objects
which have slots containing other streams, I see no reason to worry
about fast GC of them. Statistically, I bet their components will
tend to (not really coincidentally) get closed anyway by other
mechanisms. eg, consider:
(WITH-OPEN-FILE (FILE-STREAM ...)
(LET ((ECHO-STREAM (MAKE-ECHO-STREAM STREAM *TERMINAL-IO*)))
...))
The file stream will get closed fine by the WITH-OPEN-FILE. The echo
stream (holding the closed file stream) will eventually get cleaned
up by the GC. That should be fine. No one's going to miss the couple
of conses which is presumably the only resource being used in the
meantime.
It's true that there may be certain situations where you might think
you want ECHO-STREAM-P, ECHO-STREAM-INPUT-STREAM, and
ECHO-STREAM-OUTPUT-STREAM operations in order to clean up the loose
ends. Eg, you might have done:
(DEFVAR *ECHO-STREAM* (MAKE-ECHO-STREAM (OPEN ...) *TERMINAL-IO*))
and maybe you later want to close the encapsulated real stream, but my
feeling is that it was so easy for you to have done:
(DEFVAR *FILE-STREAM* (OPEN ...))
(DEFVAR *ECHO-STREAM* (MAKE-ECHO-STREAM *FILE-STREAM* *TERMINAL-IO*))
that there just isn't any way to claim that the language didn't let
you do what you wanted to do. In fact, if someone else wrote the module
that gave you the pointer to the echo stream and that person wouldn't
give you the encapsulated stream, maybe it was for a reason. If so,
you're asking a lot by claiming it should be ok to be closing that
encapsulated stream...
∂19-Aug-86 1556 pyramid!bein@hplabs.HP.COM streams ...
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 19 Aug 86 15:55:49 PDT
Received: by hplabs.HP.COM ; Tue, 19 Aug 86 15:54:54 pdt
Received: by pyramid (5.51/3.14)
id AA20141; Tue, 19 Aug 86 12:52:19 PDT
Date: 19 Aug 1986 12:52 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: streams ...
To: common-lisp@su-ai
Message-Id: <524862532/bein@pyramid>
Sorry for all the confusion. Now for a fresh batch.
My questions are motivated by what is supposed to happen when
a stream which is composed of other streams runs into one of the
standard streams (e.q. original *standard-input*,*standard-output*,
or *terminal-io*). Note that I am assuming that it is erroneous
to bash the original streams. I do not know whether it should cause
an error or simply do nothing. My feeling is that either is desirable
at different times. I also can imagine cases where one explicitly
wants to bash one of the original streams. Any interactive error/query system
ought to be able to throw its hands up when someone closes *terminal-io*.
My proposal for handling this mess without forcing true believers
on either side of the question is:
(1) Provide a stream operation which marks a stream as "NEVER-CLOSE".
When CLOSE (either directly or via a CLOSE on some composed stream)
hits one of these it ignores it and returns. We could designate
this as a "DINER" stream since it is always open.
(2) Provide a stream operation which marks a stream as "COMPLAIN-IF-CLOSED".
When CLOSE (same conditions as above) hits one of these it flames
out and causes an error.
Any stream which has neither of these attributes is fair game
for closing either directly or via recursion. Both options may of
course be turned off if a user desires it.
Establish well-defined defaults for any of the standard streams
so that one can write "portable" code. Perhaps neither attribute
should be on when a stream is created. Of course this does not
help much when *terminal-io* appears out of nowhere as far as
any user is concerned.
I agree with those people who believe a close on a composed-stream
(echo,synonym,two-way,concatenated,broadcast) should render the
top level stream unusable.
While on the subject, I think that it would be reasonable to be
able to query a composed stream. It would also be reasonable to
make the various kinds of streams be distinct types (each a subtyp of STREAM)
so the typing system could help differentiate between the streams.
Of course we will have to draw some distinction between "portable"
streams and all the other kinds which implementers have added.
More food for thought -- what do people think is reasonable to
do with *terminal-io* if the process is running without any kind
of connection to an interactive device? I have seen different
approaches. I personally like the idea that use of *terminal-io*
when no kind of interactive device exists should cause some kind
of merciless death. This has implications for error/query systems
of course.
--David
∂19-Aug-86 1827 sridhar%tekecs.tek.csnet@CSNET-RELAY.ARPA documentation strings in BOA constructors ?
Received: from CSNET-RELAY.ARPA by SAIL.STANFORD.EDU with TCP; 19 Aug 86 18:27:25 PDT
Received: from tektronix by csnet-relay.csnet id ae12858; 19 Aug 86 18:43 EDT
Received: by tektronix.TEK (5.31/6.16)
id AA29746; Tue, 19 Aug 86 14:22:27 PDT
Received: by tekecs.GWD.TEK (5.16/6.16)
id AA03925; Tue, 19 Aug 86 14:23:25 PDT
From: "S. Sridhar" <sridhar%tekecs.tek.csnet@CSNET-RELAY.ARPA>
Message-Id: <8608192123.AA03925@tekecs.GWD.TEK>
Date: Tue, 19 Aug 86 14:23:23 PDT
To: common-lisp@SU-AI.ARPA
Subject: documentation strings in BOA constructors ?
Suppose you have :
(defstruct (point (:constructor make-point (x y) "this makes a point"))
x y)
There is no mention on page315-316 in CltL about having
documentation strings for such functions.
Our implementation does:
(documentation 'make-point 'function) => nil.
What should the "correct" behaviour be?
--sridhar
∂19-Aug-86 1840 RAM@C.CS.CMU.EDU documentation strings in BOA constructors ?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Aug 86 18:40:32 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 19 Aug 86 21:38:44-EDT
Date: Tue, 19 Aug 1986 21:38 EDT
Message-ID: <RAM.12232181270.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "S. Sridhar" <sridhar%tekecs.tek.csnet@CSNET-RELAY.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: documentation strings in BOA constructors ?
In-reply-to: Msg of 19 Aug 1986 17:23-EDT from S. Sridhar <sridhar%tekecs.tek.csnet at CSNET-RELAY.ARPA>
Date: Tuesday, 19 August 1986 17:23-EDT
From: S. Sridhar <sridhar%tekecs.tek.csnet at CSNET-RELAY.ARPA>
Re: documentation strings in BOA constructors ?
Suppose you have :
(defstruct (point (:constructor make-point (x y) "this makes a point"))
x y)
I think it clear that this is illegal and that there is no way to
specify doc strings in DEFSTRUCT. Although a possible area for
extensions, it not a big problem since SETF of DOCUMENTATION can be
used to given function documentation to any function.
If we were to extend DEFSTRUCT so that the functions could be directly
documented, then the extension should apply to *all* defstruct
generated functions, and not just BOA constructors.
Rob
∂20-Aug-86 0540 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM "fonted" characters in CL
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 Aug 86 05:40:36 PDT
Received: from FIREBIRD.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5857; Wed 20-Aug-86 08:40:10 EDT
Date: Wed, 20 Aug 86 08:40 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: "fonted" characters in CL
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <860802175500.1.DCP@FIREBIRD.S4CC.Symbolics.COM>
Message-ID: <860820084000.8.DCP@FIREBIRD.S4CC.Symbolics.COM>
I propose we eliminate char-font-limit and the associated concepts from
the language. Either that or make the specification considerably more
tight and detailed saying how >numeric< values are interpreted. Either
that, or specify some >symbolic< notion of "fonts" we can live with.
Symbolics found that the CL notion of "fonts" is not very portable, nor
is it very useful. Therefore, char-font-limit => 1 and (char-font
<char>) =always=> 0. This is in accordance with CLtL, but it doesn't
help us move code to other Common Lisp implementations, and it doesn't
help others port to our system.
What we have done instead (note I don't want to push this and I'm not
sure the development staff does either since only beta-test sites have
seen this so far) is to define a character to have the following
attributes:
A character set
A code within the character set
Bits
Style
The character set and code within character set is roughly char-code.
Bits are as per CLtL. Style is a symbolic notion of what the characters
LOOK like, for example, bold, italic, small, very-large, fixed width,
etc, and combinations. A "font" is a set of glyphs. A font is mapped
to by the triple character-set, style and output device. There are
probably some lies in this description; our documentation is clearer and
more verbose.
My point is that the current numbering scheme is a holdover from 1970's
text formatters (TJ6, R, etc) and the simplistic mapping of those to the
MIT Lisp Machines editor buffers. The numbers in those systems are
relative to something; the numbers in CLtL aren't relative to anything.
Those ideas don't hold in real production systems.
∂20-Aug-86 1040 RICE@SUMEX-AIM.ARPA Defstruct and Documentation.
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Aug 86 10:40:33 PDT
Date: Wed 20 Aug 86 09:59:37-PDT
From: James Rice <Rice@SUMEX-AIM.ARPA>
Subject: Defstruct and Documentation.
To: Common-Lisp@SU-AI.ARPA
Message-ID: <12232348944.62.RICE@SUMEX-AIM.ARPA>
I agree that doc string should be allowed in ALL
defstruct generated functions.
I also think that Declarations should be allowed.
There may well be good reasons for wanting to
(declare (optimize (safety 3) (speed 0))).
Particularly whilst debugging.
Rice.
-------
∂22-Aug-86 1333 @MC.LCS.MIT.EDU,@SEBASTIAN.THINK.COM:gls@AQUINAS.THINK.COM 1986 Lisp conference bibliography
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Aug 86 13:32:43 PDT
Received: from Godot.Think.COM by MC.LCS.MIT.EDU 22 Aug 86 14:09:45 EDT
Received: from SEBASTIAN.THINK.COM by Godot.Think.COM; Fri, 22 Aug 86 14:05:52 edt
Date: Fri, 22 Aug 86 14:06 EDT
From: Guy Steele <gls@Think.COM>
Subject: 1986 Lisp conference bibliography
To: common-lisp@SU-AI.ARPA, rrrs-authors@MC.LCS.MIT.EDU
Cc: gls@AQUINAS
Message-Id: <860822140628.4.GLS@SEBASTIAN.THINK.COM>
With the help of Bill Scherlis, I have massaged the table of contents
(with some corrections) for the 1986 ACM Conference on Lisp and
Functional Programming into the form of a bibliography database suitable
for use with LaTeX/BibTeX and (almost) SCRIBE. The database has been
tested with BibTeX, and uses TeX conventions for forcing capitalization
and for accenting characters (there are three accents acute, one umlaut,
and one "i" with a circumflex over it). The database should require
only slight modification to make it suitable for use with SCRIBE.
I am mailing out the database in the interest of making it easier for
everyone to refer to all these great papers from the conference. The
database follows at the end of this message, followed by the BibTeX
transcription of it for a bibliography format very similar to that
required by CACM. (I considered just mailing out a pointer to an
FTP-able file, but I find that in practice this method is rather clumsy
and people don't use it.)
--Guy
----------------------------------------------------------------
@InProceedings(LAWS-IN-MIRANDA
,Key = "Thompson"
,Author = "Simon Thompson"
,Title = "Laws in {M}iranda"
,Pages = "1-12"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(MINI-ML
,Key = "Clement"
,Author = "Dominique Cl\'ement and {Jo\"elle} Despeyroux and Thierry Despeyroux and Gilles Kahn"
,Title = "A Simple Applicative Language: {M}ini-{ML}"
,Pages = "13-27"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING
,Key = "Gifford"
,Author = "David K. Gifford and John M. Lucassen"
,Title = "Integrating Functional and Imperative Programming"
,Pages = "28-38"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EXPERIENCE-WITH-AN-UNCOMMON-LISP
,Key = "Alberga"
,Author = "Cyril N. Alberga and Chris Bosman-Clark and Martin Mikelsons and Mary S. Van Deusen and Julian Padget"
,Title = "Experience with an Uncommon {L}isp"
,Pages = "39-53"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP
,Key = "Padget"
,Author = "Julian Padget and others"
,Title = "Desiderata for the Standardisation of {L}isp"
,Pages = "54-66"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP
,Key = "Brooks"
,Author = "Rodney A. Brooks and David B. Posner and James L. McDonald and Jon L. White and Eric Benson and Richard P. Gabriel"
,Title = "Design of an Optimizing, Dynamically Retargetable Compiler for {C}ommon {L}isp"
,Pages = "67-85"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(IMPLEMENTATION-OF-PC-SCHEME
,Key = "Bartley"
,Author = "David H. Bartley and John C. Jensen"
,Title = "The Implementation of {PC} {S}cheme"
,Pages = "86-93"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES
,Key = "Fairbairn"
,Author = "Jon Fairbairn and Stuart C. Wray"
,Title = "Code Generation Techniques for Functional Languages"
,Pages = "94-104"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES
,Key = "Knight"
,Author = "Tom Knight"
,Title = "An Architecture for Mostly Functional Languages"
,Pages = "105-112"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION
,Key = "Lemaitre"
,Author = "M. Lema\↑\itre and M. Castan and M.-H. Durand and G. Durrieu and B. Lecussan"
,Title = "Mechanisms for Efficient Multiprocessor Combinator Reduction"
,Pages = "113-121"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(CURRY-CHIP
,Key = "Ramsdell"
,Author = "John D. Ramsdell"
,Title = "The {CURRY} Chip"
,Pages = "122-131"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(VARIATIONS-ON-STRICTNESS-ANALYSIS
,Key = "Bloss"
,Author = "Adrienne Bloss and Paul Hudak"
,Title = "Variations on Strictness Analysis"
,Pages = "132-142"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EXPANSION-PASSING-STYLE
,Key = "Dybvig"
,Author = "R. Kent Dybvig and Daniel P. Friedman and Christopher T. Haynes"
,Title = "Expansion-Passing Style: Beyond Conventional Macros"
,Pages = "143-150"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(HYGIENIC-MACRO-EXPANSION
,Key = "Kohlbecker"
,Author = "Eugene Kohlbecker and Daniel P. Friedman and Matthias Felleisen and Bruce Duba"
,Title = "Hygienic Macro Expansion"
,Pages = "151-161"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EXACT-REAL-ARITHMETIC
,Key = "Boehm"
,Author = "Hans-J. Boehm and Robert Cartwright and Mark Riggle and Michael J. O'Donnell"
,Title = "Exact Real Arithmetic: A Case Study in Higher Order Programming"
,Pages = "162-173"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(RECONFIGURABLE-RETARGETABLE-BIGNUMS
,Key = "White"
,Author = "Jon L. White"
,Title = "Reconfigurable, Retargetable Bignums: A Case Study in Efficient, Portable {L}isp System Building"
,Pages = "174-191"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR
,Key = "Steenkiste"
,Author = "Peter Steenkiste and John Hennessy"
,Title = "{L}isp on a Reduced-Instruction-Set-Processor"
,Pages = "192-201"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW
,Key = "Sarkar"
,Author = "Vivek Sarkar and John Hennessy"
,Title = "Partitioning Parallel Programs for Macro-Dataflow"
,Pages = "202-211"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(NORMA-GRAPH-REDUCTION-PROCESSOR
,Key = "Scheevel"
,Author = "Mark Scheevel"
,Title = "{NORMA}: A Graph Reduction Processor"
,Pages = "212-219"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(FOUR-STROKE-REDUCTION-ENGINE
,Key = "Clack"
,Author = "Chris Clack and Simon L. Peyton Jones"
,Title = "The Four-Stroke Reduction Engine"
,Pages = "220-232"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS
,Key = "Lee"
,Author = "Peter Lee and Uwe Pleban"
,Title = "On the Use of {L}isp in Implementing Denotational Semantics"
,Pages = "233-248"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES
,Key = "Nielson"
,Author = "Hanne R. Nielson and Flemming Nielson"
,Title = "Semantics Directed Compiling for Functional Languages"
,Pages = "249-257"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(CONNECTION-GRAPHS
,Key = "Bawden"
,Author = "Alan Bawden"
,Title = "Connection Graphs"
,Pages = "258-265"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE
,Key = "Mauny"
,Author = "Michel Mauny and Asc\'ander Su\'arez"
,Title = "Implementing Functional Languages in the Categorical Abstract Machine"
,Pages = "266-278"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(CONNECTION-MACHINE-LISP
,Key = "Steele"
,Author = "Steele, Guy L., Jr. and W. Daniel Hillis"
,Title = "Connection Machine LISP: Fine-Grained Parallel Symbolic Processing"
,Pages = "279-297"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(MYSTERY-OF-THE-TOWER-REVEALED
,Key = "Wand"
,Author = "Mitchell Wand and Daniel P. Friedman"
,Title = "The Mystery of the Tower Revealed: A Non-Reflective Description of the Reflective Tower"
,Pages = "298-307"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS
,Key = "Mitchell"
,Author = "John C. Mitchell"
,Title = "A Type-Inference Approach to Reduction Properties and Semantics of Polymorphic Expressions (summary)"
,Pages = "308-319"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(EQUATIONS-SETS-AND-REDUCTION-SEMANTICS
,Key = "Jayaraman"
,Author = "Bharat Jayaraman and Frank S. K. Silbermann"
,Title = "Equations, Sets, and Reduction Semantics for Functional and Logic Programming"
,Pages = "320-331"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES
,Key = "Thatte"
,Author = "Satish R. Thatte"
,Title = "Towards a Semantic Theory for Equational Programming Languages"
,Pages = "332-342"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING
,Key = "Lermen"
,Author = "Claus-Werner Lermen and Dieter Maurer"
,Title = "A Protocol for Distributed Reference Counting"
,Pages = "343-350"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION
,Key = "Hudak"
,Author = "Paul Hudak"
,Title = "A Semantic Model of Reference Counting and its Abstraction (detailed summary)"
,Pages = "351-363"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
@InProceedings(DISTRIBUTED-COPYING-GARBAGE-COLLECTION
,Key = "Rudalics"
,Author = "Martin Rudalics"
,Title = "Distributed Copying Garbage Collection"
,Pages = "364-372"
,Booktitle = "Proc.~1986 ACM Conference on Lisp and Functional Programming"
,Organization = "ACM SIGPLAN/SIGACT/SIGART"
,Year = "1986"
,Month = Aug
,Address = "Cambridge, Massachusetts")
----------------------------------------------------------------
\bibitem{EXPERIENCE-WITH-AN-UNCOMMON-LISP}
Alberga, Cyril N., Bosman-Clark, Chris, Mikelsons, Martin, Deusen, Mary S. Van, and Padget, Julian.
Experience with an uncommon {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 39--53.
\bibitem{IMPLEMENTATION-OF-PC-SCHEME}
Bartley, David H., and Jensen, John C.
The implementation of {PC} {S}cheme.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 86--93.
\bibitem{CONNECTION-GRAPHS}
Bawden, Alan.
Connection graphs.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 258--265.
\bibitem{VARIATIONS-ON-STRICTNESS-ANALYSIS}
Bloss, Adrienne, and Hudak, Paul.
Variations on strictness analysis.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 132--142.
\bibitem{EXACT-REAL-ARITHMETIC}
Boehm, Hans-J., Cartwright, Robert, Riggle, Mark, and O'Donnell, Michael J.
Exact real arithmetic: a case study in higher order programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 162--173.
\bibitem{OPTIMIZING-DYNAMICALLY-RETARGETABLE-COMPILER-FOR-COMMON-LISP}
Brooks, Rodney A., Posner, David B., McDonald, James L., White, Jon L., Benson, Eric, and Gabriel, Richard P.
Design of an optimizing, dynamically retargetable compiler for {C}ommon {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 67--85.
\bibitem{FOUR-STROKE-REDUCTION-ENGINE}
Clack, Chris, and Jones, Simon L. Peyton.
The four-stroke reduction engine.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 220--232.
\bibitem{MINI-ML}
Cl\'ement, Dominique, Despeyroux, {Jo\"elle}, Despeyroux, Thierry, and Kahn, Gilles.
A simple applicative language: {M}ini-{ML}.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 13--27.
\bibitem{EXPANSION-PASSING-STYLE}
Dybvig, R. Kent, Friedman, Daniel P., and Haynes, Christopher T.
Expansion-passing style: beyond conventional macros.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 143--150.
\bibitem{CODE-GENERATION-TECHNIQUES-FOR-FUNCTIONAL-LANGUAGES}
Fairbairn, Jon, and Wray, Stuart C.
Code generation techniques for functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 94--104.
\bibitem{INTEGRATING-FUNCTIONAL-AND-IMPERATIVE-PROGRAMMING}
Gifford, David K., and Lucassen, John M.
Integrating functional and imperative programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 28--38.
\bibitem{SEMANTIC-MODEL-OF-REFERENCE-COUNTING-AND-ITS-ABSTRACTION}
Hudak, Paul.
A semantic model of reference counting and its abstraction (detailed summary).
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 351--363.
\bibitem{EQUATIONS-SETS-AND-REDUCTION-SEMANTICS}
Jayaraman, Bharat, and Silbermann, Frank S. K.
Equations, sets, and reduction semantics for functional and logic programming.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 320--331.
\bibitem{ARCHITECTURE-FOR-MOSTLY-FUNCTIONAL-LANGUAGES}
Knight, Tom.
An architecture for mostly functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 105--112.
\bibitem{HYGIENIC-MACRO-EXPANSION}
Kohlbecker, Eugene, Friedman, Daniel P., Felleisen, Matthias, and Duba, Bruce.
Hygienic macro expansion.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 151--161.
\bibitem{USE-OF-LISP-IN-IMPLEMENTING-DENOTATIONAL-SEMANTICS}
Lee, Peter, and Pleban, Uwe.
On the use of {L}isp in implementing denotational semantics.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 233--248.
\bibitem{EFFICIENT-MULTIPROCESSOR-COMBINATOR-REDUCTION}
Lema\↑\itre, M., Castan, M., Durand, M.-H., Durrieu, G., and Lecussan, B.
Mechanisms for efficient multiprocessor combinator reduction.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 113--121.
\bibitem{PROTOCOL-FOR-DISTRIBUTED-REFERENCE-COUNTING}
Lermen, Claus-Werner, and Maurer, Dieter.
A protocol for distributed reference counting.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 343--350.
\bibitem{IMPLEMENTING-FUNCTIONAL-LANGUAGES-IN-THE-CATEGORICAL-ABSTRACT-MACHINE}
Mauny, Michel, and Su\'arez, Asc\'ander.
Implementing functional languages in the categorical abstract machine.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 266--278.
\bibitem{TYPE-INFERENCE-APPROACH-TO-POLYMORPHIC-EXPRESSIONS}
Mitchell, John C.
A type-inference approach to reduction properties and semantics of polymorphic expressions (summary).
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 308--319.
\bibitem{SEMANTICS-DIRECTED-COMPILING-FOR-FUNCTIONAL-LANGUAGES}
Nielson, Hanne R., and Nielson, Flemming.
Semantics directed compiling for functional languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 249--257.
\bibitem{DESIDERATA-FOR-THE-STANDARDISATION-OF-LISP}
Padget, Julian, et al.
Desiderata for the standardisation of {L}isp.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 54--66.
\bibitem{CURRY-CHIP}
Ramsdell, John D.
The {CURRY} chip.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 122--131.
\bibitem{DISTRIBUTED-COPYING-GARBAGE-COLLECTION}
Rudalics, Martin.
Distributed copying garbage collection.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 364--372.
\bibitem{PARTITIONING-PARALLEL-PROGRAMS-FOR-MACRO-DATAFLOW}
Sarkar, Vivek, and Hennessy, John.
Partitioning parallel programs for macro-dataflow.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 202--211.
\bibitem{NORMA-GRAPH-REDUCTION-PROCESSOR}
Scheevel, Mark.
{NORMA}: a graph reduction processor.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 212--219.
\bibitem{CONNECTION-MACHINE-LISP}
Steele, Jr., Guy L., and Hillis, W. Daniel.
Connection machine lisp: fine-grained parallel symbolic processing.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 279--297.
\bibitem{LISP-ON-A-REDUCED-INSTRUCTION-SET-PROCESSOR}
Steenkiste, Peter, and Hennessy, John.
{L}isp on a reduced-instruction-set-processor.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 192--201.
\bibitem{SEMANTIC-THEORY-FOR-EQUATIONAL-PROGRAMMING-LANGUAGES}
Thatte, Satish R.
Towards a semantic theory for equational programming languages.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 332--342.
\bibitem{LAWS-IN-MIRANDA}
Thompson, Simon.
Laws in {M}iranda.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 1--12.
\bibitem{MYSTERY-OF-THE-TOWER-REVEALED}
Wand, Mitchell, and Friedman, Daniel P.
The mystery of the tower revealed: a non-reflective description of the reflective tower.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 298--307.
\bibitem{RECONFIGURABLE-RETARGETABLE-BIGNUMS}
White, Jon L.
Reconfigurable, retargetable bignums: a case study in efficient, portable {L}isp system building.
In {\it Proc. 1986 ACM Conference on Lisp and Functional Programming}.
ACM SIGPLAN/SIGACT/SIGART (Cambridge, Massachusetts, August 1986), 174--191.
∂25-Aug-86 1059 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Defstruct and Documentation.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86 10:59:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67941; Mon 25-Aug-86 13:54:56 EDT
Date: Mon, 25 Aug 86 13:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Defstruct and Documentation.
To: James Rice <Rice@SUMEX-AIM.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <12232348944.62.RICE@SUMEX-AIM.ARPA>
Message-ID: <860825135423.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed 20 Aug 86 09:59:37-PDT
From: James Rice <Rice@SUMEX-AIM.ARPA>
I agree that doc string should be allowed in ALL
defstruct generated functions.
I also think that Declarations should be allowed.
There may well be good reasons for wanting to
(declare (optimize (safety 3) (speed 0))).
Particularly whilst debugging.
Shouldn't that be done as
(locally (declare (optimize (safety 3) (speed 0)))
(defstruct ...))
or (proclaim '(optimize (safety 3) (speed 0))) ?
∂25-Aug-86 1105 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM question about subtypep
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86 11:05:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67948; Mon 25-Aug-86 14:03:19 EDT
Date: Mon, 25 Aug 86 14:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: question about subtypep
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
cc: SANDRA <LOOSEMORE@UTAH-20.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12230709127.BABYL@C.CS.CMU.EDU>
Message-ID: <860825140245.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 14 Aug 1986 06:51 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Note there are some possible users of SUBTYPEP that would prefer
answers to be based on some hypothetical maximally restrictive type
system. The main example is a compiler which does compile-time type
checking when possible. Although (THE SHORT-FLOAT 1F0) is quite legal
in an implementation in which SHORT-FLOAT and SINGLE-FLOAT are
identical, it would be reasonable for the compiler to give a warning
anyway. Applications that care about this sort of thing will have to
use a variant version of subtypep that is distinct from the real
SUBTYPEP.
They'll have to do more than that. If the user wrote (THE SHORT-FLOAT 1s0)
it would read as exactly the same Lisp object as (THE SHORT-FLOAT 1f0) in an
implementation where SHORT-FLOAT and SINGLE-FLOAT are identical, so I don't
see how the compiler could distinguish these and give a warning for one but
not for the other.
My intpretation
(based on intensive meditation and reading of scripture) is that
SUBTYPEP returns information about the actual subtype relations in
your implementation.
I agree. I think that's the only consistent interpretation.
∂25-Aug-86 1117 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM Re: synonym streams..
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 25 Aug 86 11:15:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 67962; Mon 25-Aug-86 14:13:20 EDT
Date: Mon, 25 Aug 86 14:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: synonym streams..
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8608182223.AA19698@fizzy>,
<12231905873.61.HEDRICK@RED.RUTGERS.EDU>,
<12232095191.66.ACUFF@SUMEX-AIM.ARPA>,
<860819152419.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<524862532/bein@pyramid>
Message-ID: <860825141247.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I believe all of these problems would go away if programmers would follow
the rule that the same module that opens (or otherwise creates) a stream
is responsible for closing (or otherwise disposing of) it. This seems
eminently simple and sensible, and has worked well for us for many years.
∂25-Aug-86 1201 RAM@C.CS.CMU.EDU question about subtypep
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86 11:57:59 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Mon 25 Aug 86 14:56:53-EDT
Date: Mon, 25 Aug 1986 14:56 EDT
Message-ID: <RAM.12233680997.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: question about subtypep
In-reply-to: Msg of 25 Aug 1986 14:02-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Date: Monday, 25 August 1986 14:02-EDT
From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 14 Aug 1986 06:51 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Although (THE SHORT-FLOAT 1F0) is quite legal in an
implementation in which SHORT-FLOAT and SINGLE-FLOAT are
identical, it would be reasonable for the compiler to give a warning
anyway. Applications that care about this sort of thing will have to
use a variant version of subtypep that is distinct from the real
SUBTYPEP.
They'll have to do more than that. If the user wrote
(THE SHORT-FLOAT 1s0) it would read as exactly the same Lisp object as
(THE SHORT-FLOAT 1f0) in an implementation where SHORT-FLOAT and
SINGLE-FLOAT are identical, so I don't see how the compiler could
distinguish these and give a warning for one but not for the
other.
I realized this was a bad example after I sent the message. Instead
1F0, substitute <any expression known to be SINGLE-FLOAT>. For
example, (THE SHORT-FLOAT (THE SINGLE-FLOAT ...)).
Rob
∂25-Aug-86 2029 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA More words on the scoping of declarations
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86 20:28:13 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 8026; 25 Aug 86 23:31:36-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 37859; Mon 25-Aug-86 22:58:50-EDT
Date: Mon, 25 Aug 86 23:09 EST
Sender: mike%gold-hill-acorn@mit-live-oak.arpa
To: RAM@C.CS.CMU.EDU
From: mike%acorn@mit-live-oak.arpa
Subject: More words on the scoping of declarations
Cc: Pavel.pa@XEROX.COM, Common-Lisp@SU-AI.ARPA
Date: Mon, 18 Aug 1986 13:56 EDT
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
.....
It is evident that you do have a theory of variable binding, but
you don't really attempt to formalize it to the point where
declartion semantics becomes obvious. You theory is based on the idea
that declaration scoping should follow the same scope rules as
variables. It is a property of this theory that a declaration for a
specific name cannot refer to multipel variables which have the same
name.
So far as the application of the theory goes, the main problem
that I see is with LET* and possibly other places where sequential
bindings happen. It is not obvious to me what the scope of
delcarations in LET* should be, even if we disallow repeated variable
names.
The scoping of a declaration in a let* should be as close as possible
to that of a let. I think repeated names should be allowed, and the
innermost one should be the one to which the declaration applies.
(let* ((a (foo a))
(b a)
(a 7))
(declare (type fixnum a)
(type frobboz b))
...a...b...)
The only "a" which is a fixnum here is the one which gets the value 7.
Semantically, the form should be equivalent to:
(let ((a (foo a)))
(let ((b a))
(declare (type frobboz b))
(let ((a 7))
(declare (type fixnum a))
... a ...b..)
This means that the semantics of declaration in let* is exactly as
if you moved the declarations up into a nested let construct,
except for the case of a repeated identifier, where the innermost
name is the one the declaration applies to.
There are of course ambiguous cases where expressing exactly the
declarations you want requires breaking up a let* into two nested
let*'s so that you can stick a declare in between. I don't see this
as a tragedy. It's still better than the situation in most programming
languages, where the names of identifiers are often chosen to reflect
their type......
In summary, two things. (1) I think Pavel's proposal is right.
(2) I think the "theory" should be extended to reflect the "innermost"
principle for sequential binding constructs.
...mike beckerle
Gold Hill Computers
∂25-Aug-86 2154 @MIT-LIVE-OAK.ARPA,@GOLD-HILL-ACORN.LCS.MIT.EDU:mike%gold-hill-acorn@MIT-LIVE-OAK.ARPA "fonted" characters in CL
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 86 21:53:56 PDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 8037; 26 Aug 86 00:57:49-EDT
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 37862; Tue 26-Aug-86 00:03:47-EDT
Date: Tue, 26 Aug 86 00:14 EST
Sender: mike%gold-hill-acorn@mit-live-oak.arpa
To: DCP@QUABBIN.SCRC.Symbolics.COM
From: mike%acorn@mit-live-oak.arpa
Subject: "fonted" characters in CL
Cc: Common-Lisp@SU-AI.ARPA
Date: Wed, 20 Aug 86 08:40 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
I propose we eliminate char-font-limit and the associated concepts from
the language.
I agree, vehemently.
Either that or make the specification considerably more
tight and detailed saying how >numeric< values are interpreted. Either
that, or specify some >symbolic< notion of "fonts" we can live with.
I don't think this is a good idea for CL, see more below.
Symbolics found that the CL notion of "fonts" is not very portable, nor
is it very useful.
......
What we have done instead (note I don't want to push this and I'm not
sure the development staff does either since only beta-test sites have
seen this so far) is to define a character to have the following
attributes:
A character set
A code within the character set
Bits
Style
The character set and code within character set is roughly char-code.
Bits are as per CLtL. Style is a symbolic notion of what the characters
LOOK like, for example, bold, italic, small, very-large, fixed width,
etc, and combinations. A "font" is a set of glyphs. A font is mapped
to by the triple character-set, style and output device.
Let me dramatize for a second to make a point. I don't see "size",
"rotation", "shading", "projection", "mask", "color",... why don't we
just put TROFF in format macros and throw that in too. This
would give us a full composition language....
Now don't get me wrong. I agree completely with the MOTIVATION for
the new symbolics way of representing characters. It acknowledges
that characters are complex objects having lots of relative
attributes, etc., and that quick little hacks with font "bits" and
numbers up to some limit won't work for real high-quality output.
However, I see no reason for this to become part of a language
standard. The users of common lisp are NOT primarily typographers.
High quality screen output should be discussed w.r.t. a window system
standard. (Note: there seems to be no de-facto standard here.) High
quality printer output should be discussed w.r.t. an output device
standard. (Note: there are two emerging standards here... Postscript
and Interpress. Trademarks of somebody...) Without these notions,
having "font" information is just clutter in the language.
Concretely. I think char-font-limit = 1, (char-font <char>) = 0
should always be the case, and that ultimately we should drop
the font concept from the language. (like I said, I agree vehemently...)
...mike beckerle
Gold Hill Computers
∂26-Aug-86 0057 pyramid!bein@hplabs.HP.COM re: synonym streams..
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 26 Aug 86 00:57:25 PDT
Received: by hplabs.HP.COM ; Tue, 26 Aug 86 00:55:52 pdt
Received: by pyramid (5.51/3.14)
id AA24121; Tue, 26 Aug 86 00:50:52 PDT
Date: 26 Aug 1986 00:48 PDT
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: re: synonym streams..
To: common-lisp@su-ai
Message-Id: <525418881/bein@pyramid>
Regarding David Moon's comment about what sensible programmers should do,
I agree wholeheartedly. It is somewhat clearer that streams come
in more flavors than just what OPEN will return (as currently defined
in both CLtL and various LispMachine manuals for existing implementations).
David's suggestion seems to omit the need for making streams more usable.
Closing down a stream (whether it be the product of some composite
operation like make-broadcast-stream or not) is a reasonable thing
to want to do. I think the issue here is deciding whether or not
the programmer/user has an adequate amount of flexibility in
this area.
ONE QUESTION for the designers:
Why was there no function like
(MAKE-FILTER-STREAM '<input-stream>
'<output-stream>
'<function-of-2-args>)
where function gets passed both streams and does input from <input-stream>
filtering it in some way and possibly doing some output to
<output-stream>?
I really wish that the original specification for streams had
included itself in the typing system. I feel that it would have
been cleaner to define one function called:
(stream-message stream :keyword <...>)
much in the object-oriented spirit. I can think of some esoteric
methods I would have added certainly, but the most important ones
include being able to differentiate amongst streams, interrogating
streams and applying a handful of options to alter how close behaves
on any stream.
Below the ====='ed line is my proposal.
I welcome comments,modifications,critcisms, et al to the proposal
presented below.
--David
=============================================================================
(typep stream 'stream)
(stream-message stream :type)
Returns stream type, e.g. synonym-stream.
This should return something rather specialized.
Those who feel that TYPE-OF would answer this
need might consider what kinds of hair seem
to be in most implementations of TYPE-OF.
(stream-message stream :operations)
Returns a list of operations which make
sense for this stream. Defined to not
recurse into streams underneath.
(typep stream 'broadcast-stream)
(stream-message stream :broadcasters)
Returns a list of the streams to broadcast to.
(typep stream 'synonym-stream)
(stream-message stream :synonym)
Returns the symbol which the stream is synonymous with.
(stream-message stream :sanity-check)
Returns T if the stream contains no loops like
the kind which bite KMP and others (me too). Otherwise,
returns NIL which means that this stream is inherently
unsafe. NOTE: I know this is out of place and definitely
smells bad. I could live with out this one I guess.
(or (typep stream 'two-way-stream)
(typep stream 'echo-stream))
(stream-message stream :input)
Returns the input stream.
(stream-message stream :output)
Returns the output stream.
(I think of echo streams as a specialization of two-way streams.)
(typep stream 'concatenated-stream)
(stream-message stream :sources)
Returns a list of the input streams.
(typep stream 'stream) ;; CLOSE attributes
(stream-message stream :close-forever)
Marks this stream as one which CLOSE
should render unsuable and which
should have CLOSE applied to its
children. This is the DEFAULT for
streams produced by OPEN or
MAKE-<COMMON>-STREAM.
(stream-message stream :close-never)
Marks this stream as always open.
A CLOSE will not look to see if
this stream has children.
(stream-message stream :close-parent)
Marks this stream as one which CLOSE
renders unusable but does not touch
any streams underneath.
(stream-message stream :close-children)
Marks this stream as one which never closes
but a CLOSE applied to it will be applied
to streams underneath.
(typep stream 'stream) ;; CLOSE and ERROR
(stream-message stream :close-no-error)
Permit this stream to be CLOSEd. This
is the DEFAULT for streams produced by
OPEN,MAKE-<COMMON>-STREAM.
(stream-message stream :close-error)
Marks this stream in such a way that
a CLOSE of it causes an error. Handy for
things like (close *terminal-io*) where
it probably does not make sense to close it.
∂26-Aug-86 0653 preece%ccvaxa@gswd-vms.ARPA Re: More words on the scoping of dec
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 26 Aug 86 06:53:37 PDT
Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.51/)
id AA13672; Tue, 26 Aug 86 08:52:57 CDT
Message-Id: <8608261352.AA13672@gswd-vms.ARPA>
Date: Tue, 26 Aug 86 08:51:24 cdt
From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@su-ai.arpa
Subject: Re: More words on the scoping of dec
> From: mike%acorn@mit-live-oak.arpa
> The scoping of a declaration in a let* should be as close as possible
> to that of a let. I think repeated names should be allowed, and the
> innermost one should be the one to which the declaration applies.
----------
I agree that repeated names should be allowed, but I think the
declaration should apply to the ENTIRE set of bindings, not just
the innermost. If the user wants to have different declarations
for the repeated instances of the name, she can break the LET*
into nested LET*s. If, on the other hand, she is playing games
and doing a multi-step calculation of a value in the header of the LET*,
the one declaration should apply to all parts of it.
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@gswd-vms
∂26-Aug-86 0904 RAM@C.CS.CMU.EDU More words on the scoping of declarations
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Aug 86 09:04:12 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 26 Aug 86 12:03:22-EDT
Date: Tue, 26 Aug 1986 12:03 EDT
Message-ID: <RAM.12233911549.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: mike%acorn@LIVE-OAK.LCS.MIT.EDU
Cc: Common-Lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM
Subject: More words on the scoping of declarations
In-reply-to: Msg of 26 Aug 1986 00:09-EDT from mike%acorn at mit-live-oak.arpa
Actually I wasn't primarily worried about the meaning of repeated
LET* variables, supposing they are legal. I was more concerned about
the scope in LET* of declarations which don't pertain to a particular
variable. In LET* there isn't a clear environment division which can
contain these "pervasive" declarations.
I can think of two reasonable scopes for pervasive declarations in LET*:
1] The declarations syntactically enclose all of the incremental
environments in the LET*, and thus affect all init forms as well as
the body.
2] The declarations affect only the innermost environment, and thus
are in effect only in the body, and in none of the init forms.
I favor the latter interpretation, since it more closely resembles the
scoping in LET. In any case, it seems that LET* must special-case the
declarations depending on whether they are "pervasive" or not.
Although the concept of a pervasive declaration seems to cause Pavel
to cringe, I am not yet convinced that it is a bankrupt idea.
Rob
∂27-Aug-86 0925 Gregor.pa@Xerox.COM Fixing optional arguments?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Aug 86 09:24:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 AUG 86 09:24:26 PDT
Date: 27 Aug 86 09:24 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Fixing optional arguments?
To: Common-Lisp@SU-AI.arpa
cc: Gregor.pa@Xerox.COM
Message-ID: <860827-092426-1167@Xerox>
A standard problem with optional arguments in Common Lisp is that it
difficult to use the fact that a function was only called with n
arguments to call some other function with only n arguments. For
example:
(defun foo (x &optional (y nil y-p))
...
(if y-p
(bar x y)
(bar x)))
This is a proposed solution to that problem.
- The default default value for an optional argument is the value of the
constant UNSUPPLIED-OPTIONAL-ARGUMENT (instead of nil).
So given the definition (defun foo (x &optional y) y). (foo 1) would
return the value of the constant unsupplied-optional-argument.
- When function call sees the value of unsupplied-optional-argument
being used as an argument to a function, it treats it as an unsupplied
value for an optional argument. As an important performance
optimization, any arguments following unsupplied-optional-argument are
also discarded.
The example becomes:
(defun foo (x &optional y)
...
(bar x y) ..)
In addition, it is possible to write code like:
...
(when <something>
;; We are only going to call baz with 2 arguments.
(setq arg-3 unsupplied-optional-argument))
(baz arg-1 arg-2 arg-3 arg-4)
In this example, the call to baz will be as if only two arguments were
supplied.
The supplied-p variable stuff is also no longer needed since the same
thing can be determined by using (unsupplied-optional-argument-p <arg>).
∂27-Aug-86 1058 FAHLMAN@C.CS.CMU.EDU Fixing optional arguments?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Aug 86 10:54:26 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 27 Aug 86 13:52:08-EDT
Date: Wed, 27 Aug 1986 13:51 EDT
Message-ID: <FAHLMAN.12234193461.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregor Kiczales <Gregor.pa@XEROX.COM>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Fixing optional arguments?
In-reply-to: Msg of 27 Aug 1986 12:24-EDT from Gregor Kiczales <Gregor.pa at Xerox.COM>
This could be done by convention, without any change to the language, as
long as both the caller and the callee know and observe the same
convention.
-- Scott
∂27-Aug-86 1846 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Fixing optional arguments?
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 27 Aug 86 18:46:22 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7902; Wed 27-Aug-86 21:14:17 EDT
Date: Wed, 27 Aug 86 21:14 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Fixing optional arguments?
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Gregor Kiczales <Gregor.pa@XEROX.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12234193461.BABYL@C.CS.CMU.EDU>
Message-ID: <860827211406.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Wed, 27 Aug 1986 13:51 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
This could be done by convention, without any change to the language, as
long as both the caller and the callee know and observe the same
convention.
Sure, but I think that misses the point. Suppose I have a function that
looks like
(defun foo (a &optional b c &rest d &key e)
...)
and somebody calls it with B or C being the value of unsupplied-... That
means I would have to put a prelude function in that looks roughly like
(tagbody
(cond ((eq b unsupplied...)
(go b-is-unsupplied))
((eq c unsupplied...)
(go c-is-unsupplied)))
b-is-unsupplied
(setq c unsupplied...)
c-is-unsupplied
(setq d nil
e unsupplied...))
(setq c unsupplied...)
(go c-unsupplied))
in order to make all the unsupplieds consistent.
It also means I can't
(when (not b)
(setq b (compute-b-default)))
since B is not NIL. This is a rather major change to the language.
There is probably some validity behind it someplace, but history
probably won't allow it.
Gregor, does multiple-value-call solve any of your problems?
(multiple-value-call #'bar
arg-1 arg2
(if <something>
(values)
(values arg-3 arg-4)))
?
∂28-Aug-86 1122 Gregor.pa@Xerox.COM Re: Fixing optional arguments?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Aug 86 11:22:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 AUG 86 11:19:26 PDT
Date: 28 Aug 86 11:18 PDT
Sender: Gregor.pa@Xerox.COM
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
Subject: Re: Fixing optional arguments?
In-reply-to: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>'s message
of Wed, 27 Aug 86 21:14 EDT
To: DCP@QUABBIN.SCRC.Symbolics.COM
cc: Fahlman@C.CS.CMU.EDU, Gregor.pa@Xerox.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <860828-111926-2340@Xerox>
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Fixing optional arguments?
and somebody calls it with B or C being the value of unsupplied-... That
means I would have to put a prelude function in that looks roughly like
No you wouldn't have to put such a prelude. As soon as function call sees the
value of unsupplied-optional-argument it drops the rest of the arguments on
the floor.
(multiple-value-call #'bar
arg-1 arg2
(if <something>
(values)
(values arg-3 arg-4)))
I don't see that as being much easier than saying:
(if <something>
(foo arg-1 arg-2)
(foo arg-1 arg-2 arg-3 arg-4))
∂28-Aug-86 1216 RAM@C.CS.CMU.EDU Fixing optional arguments?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 86 12:14:07 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 28 Aug 86 15:14:00-EDT
Date: Thu, 28 Aug 1986 15:13 EDT
Message-ID: <RAM.12234470538.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Gregor Kiczales <Gregor.pa@XEROX.COM>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Fixing optional arguments?
In-reply-to: Msg of 28 Aug 1986 14:18-EDT from Gregor Kiczales <Gregor.pa at Xerox.COM>
I don't think that we should significantly change the language in
a way that will adversely affect the performance of many
implementations to get an enhancement that is of marginal utility at
best.
Many implementations on stock hardware use a link-table to resolve
the optional arg entry points at load time, thus eliminating any
run-time arg-count dispatching. The change you propose would make
this impossible since there would be no way for the compiler to tell
how many "real" arguments are being supplied.
Even if we disregard this efficiency issue, we would have good
reason to reject the proposal as being too radical a change in
language semantics.
Rob
∂29-Aug-86 0956 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: Fixing optional arguments?
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 29 Aug 86 09:56:00 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 8447; 29 Aug 86 12:52:16 EDT
Date: Fri, 29 Aug 86 12:50 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Fixing optional arguments?
To: Gregor Kiczales <Gregor.pa@Xerox.COM>,
DCP@QUABBIN.SCRC.Symbolics.COM
cc: Fahlman@C.CS.CMU.EDU, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860828-111926-234@Xerox>
Message-ID: <860829125053.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 28 Aug 86 11:18 PDT
From: Gregor Kiczales <Gregor.pa@Xerox.COM>
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Fixing optional arguments?
and somebody calls it with B or C being the value of unsupplied-... That
means I would have to put a prelude function in that looks roughly like
No you wouldn't have to put such a prelude. As soon as function call sees the
value of unsupplied-optional-argument it drops the rest of the arguments on
the floor.
I guess that depends a lot on how your architecture does function
calling. Many machines currently do not look at the value of the
arguments, partly for historical reasons, partly for speed and perhaps
partly for ease of implementation. It would also have to be very
careful if some CL extension included the MultiLisp concept of futures.
In that case, you DON'T want to examine the data (or you have to do so
very carefully) for fear of forcing the contained computation to
complete.
∂31-Aug-86 1341 LOOSEMORE@UTAH-20.ARPA question about pprint, *print-pretty*
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 31 Aug 86 13:41:15 PDT
Date: Sun 31 Aug 86 14:39:44-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: question about pprint, *print-pretty*
To: common-lisp@SU-AI.ARPA
Message-ID: <12235272600.9.LOOSEMORE@UTAH-20.ARPA>
In Common Lisp, both print and pprint are defined to print out a newline
*before* the form rather than after. This is backwards from PSL, where
the prettyprinter indents things relative to the "current" character
position on the output stream, and prints a newline afterwards. Is there
a portable way I can get the same kind of relative indentation in Common
Lisp? Exactly what turning on *print-pretty* does is left rather vague --
the manual just says the printer should insert more whitespace. Is there
some overwhelming reason why these functions were defined "backwards" in
the first place that I've missed?
-Sandra
-------
∂02-Sep-86 0909 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM question about pprint, *print-pretty*
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86 09:08:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72015; Tue 2-Sep-86 12:05:08 EDT
Date: Tue, 2 Sep 86 12:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: question about pprint, *print-pretty*
To: common-lisp@SU-AI.ARPA
In-Reply-To: <12235272600.9.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860902120503.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun 31 Aug 86 14:39:44-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
In Common Lisp, both print and pprint are defined to print out a newline
*before* the form rather than after. This is backwards from PSL, where
the prettyprinter indents things relative to the "current" character
position on the output stream, and prints a newline afterwards. Is there
a portable way I can get the same kind of relative indentation in Common
Lisp? Exactly what turning on *print-pretty* does is left rather vague --
the manual just says the printer should insert more whitespace. Is there
some overwhelming reason why these functions were defined "backwards" in
the first place that I've missed?
I don't know if this is an overwhelming reason, but PRINT has always printed
the newline first, all the way back to Lisp 1.5 (check the blue and white Lisp 1.5
manual). I think it's intentional that the definition of what it means to
print prettily is left rather vague, since different implementations have
different ideas about what looks pretty and about how effort they are willing
to expend to make something look pretty.
Surely binding *PRINT-PRETTY* to T is not supposed to turn PRIN1 into
PPRINT. In other words, PRIN1 with *PRINT-PRETTY* = T should not print
a leading newline, should indent things relative to the current
character position on the output stream, and should not print a trailing
newline. Next time the manual should include definitions of all of these
functions in terms of WRITE, instead of only defining half of them!
∂02-Sep-86 0909 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM question about pprint, *print-pretty*
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86 09:09:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72016; Tue 2-Sep-86 12:05:55 EDT
Date: Tue, 2 Sep 86 12:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: question about pprint, *print-pretty*
To: common-lisp@SU-AI.ARPA
In-Reply-To: <12235272600.9.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860902120550.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun 31 Aug 86 14:39:44-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
In Common Lisp, both print and pprint are defined to print out a newline
*before* the form rather than after. This is backwards from PSL, where
the prettyprinter indents things relative to the "current" character
position on the output stream, and prints a newline afterwards. Is there
a portable way I can get the same kind of relative indentation in Common
Lisp? Exactly what turning on *print-pretty* does is left rather vague --
the manual just says the printer should insert more whitespace. Is there
some overwhelming reason why these functions were defined "backwards" in
the first place that I've missed?
I don't know if this is an overwhelming reason, but PRINT has always printed
the newline first, all the way back to Lisp 1.5 (check the blue and white Lisp 1.5
manual). I think it's intentional that the definition of what it means to
print prettily is left rather vague, since different implementations have
different ideas about what looks pretty and about how effort they are willing
to expend to make something look pretty.
Surely binding *PRINT-PRETTY* to T is not supposed to turn PRIN1 into
PPRINT. In other words, PRIN1 with *PRINT-PRETTY* = T should not print
a leading newline, should indent things relative to the current
character position on the output stream, and should not print a trailing
newline. Next time the manual should include definitions of all of these
functions in terms of WRITE, instead of only defining half of them!
I think the answer to your question is to call WRITE and then TERPRI.
∂02-Sep-86 1149 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM PRINT
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 2 Sep 86 11:48:56 PDT
Received: from EMU.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72179; Tue 2-Sep-86 14:47:52 EDT
Date: Tue, 2 Sep 86 14:47 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: PRINT
To: Common-Lisp@SU-AI.ARPA
cc: KMP@SCRC-STONY-BROOK.ARPA
References: <860902120550.6.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<12235272600.9.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860902144720.7.KMP@EMU.SCRC.Symbolics.COM>
If we get to a point where we're capable of contemplating incompatible
changes to CL, I would strongly urge the group to consider renaming
PRIN1 to PRINT (and, obviously, renaming what's currently called PRINT
to something else). Sandra's query is not an isolated one. There is
wide-spread confusion about what it means to "print" something because
the operator named PRINT does more than just "print" a thing. eg,
the :PRINT-FUNCTION specifier in DEFSTRUCT effectively defines how to
PRIN1 something, not how to PRINT something, which I think most novices
are apt to be confused by. I think that thoughtful renaming of a few
functions to make the English and the Lisp be consistent would go a
long way toward fixing this kind of confusion.
∂02-Sep-86 1234 Masinter.pa@Xerox.COM Re: close on synonym streams, etc
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Sep 86 12:33:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 SEP 86 12:26:49 PDT
Date: 2 Sep 86 12:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: close on synonym streams, etc
In-reply-to: various
To: common-lisp@su-ai.ARPA
Message-ID: <860902-122649-1037@Xerox>
I still prefer "it is an error" to close streams not created with OPEN.
However, if there is strong sentiment to allow CLOSE on pseudo-streams
like broadcast, synonym and the like, it would be the most consistent to
define it as a no-op. That is, closing a synonym stream should have no
effect.
Why?
a) this is certainly the simplest to implement. There's no need to keep
pseudo-state "open" or "closed" on streams that would otherwise not need
them.
b) this would allow the most programs to function, when handed
pseudo-streams instead of file streams. In the example of "a program
that, when encountering end-of-file closes the inpupt stream and
returns" would work when handed a synonym stream to *standard-input*.
c) it is upward compatible-- no current program would stop functioning.
d) those implementations which "cache" some information into buffered
streams could use "close" to mean "flush the cache", although this would
have no effect on the program semantics.
∂03-Sep-86 1409 RICE@SUMEX-AIM.ARPA Documentation strings and function.
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86 14:07:15 PDT
Date: Wed 3 Sep 86 11:56:07-PDT
From: James Rice <Rice@SUMEX-AIM.ARPA>
Subject: Documentation strings and function.
To: Common-Lisp@SU-AI.ARPA
Message-ID: <12236040169.57.RICE@SUMEX-AIM.ARPA>
Since one is allowed to declare the following :-
(defun foo (a b)
"A docstring."
(declare (special a))
"Another docstring."
(declare (special b))
(frob a b))
what will the documentation be for Foo? The book seems to be quiet on
this issue. I would hope that it would be either a) the two strings
concatenated (i.e. when Parse-Body (what?) returns the docstring they
are all stuck together, or b) it returns a list of docstrings.
The implemetation I am using discards all but the first.
While on the subject of documentation :-
Wouldn't it be a good idea to have a Documentation function doc type
called :All or some such, returning an AList of doctype and docstring.
Since a number of CL supporting systems will have doc types of their
own (Flavor and such like) and users might want to add their own it
would be jolly good if one could guarantee getting all of the docs
for a symbol.
Rice.
-------
∂03-Sep-86 1636 VERACSD@A.ISI.EDU Deletion from Mailing-List
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86 16:36:49 PDT
Date: 3 Sep 1986 19:14-EDT
Sender: VERACSD@A.ISI.EDU
Subject: Deletion from Mailing-List
From: VERACSD@A.ISI.EDU
To: common-lisp@SU-AI.ARPA
Cc: veracsd@A.ISI.EDU
Message-ID: <[A.ISI.EDU] 3-Sep-86 19:14:52.VERACSD>
Please delete me from the mailing-list.
(I can now get it via a bulletin board.)
Thanks.
-- Cris Kobryn
∂03-Sep-86 1810 FAHLMAN@C.CS.CMU.EDU Documentation strings and function.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 86 18:10:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 3 Sep 86 21:09:46-EDT
Date: Wed, 3 Sep 1986 21:09 EDT
Message-ID: <FAHLMAN.12236108178.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: James Rice <Rice@SUMEX-AIM.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Documentation strings and function.
In-reply-to: Msg of 3 Sep 1986 14:56-EDT from James Rice <Rice at SUMEX-AIM.ARPA>
Since one is allowed to declare the following :-
(defun foo (a b)
"A docstring."
(declare (special a))
"Another docstring."
(declare (special b))
(frob a b))
What makes you think that one is allowed to declare the preceding? I
believe that this form is illegal, and that the resulting doc-string is
therefore undefined. See page 67 about a third of the way down: "It is
an error if more than one doc-string is present." Since that second
string cannot be a doc string, the second declare form is in an illegal
position.
-- Scott
∂03-Sep-86 1929 @WAIKATO.S4CC.SYMBOLICS.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM Documentation strings and function.
Received: from [128.81.51.90] by SAIL.STANFORD.EDU with TCP; 3 Sep 86 19:29:06 PDT
Received: from EMU.SCRC.Symbolics.COM by WAIKATO.S4CC.SYMBOLICS.COM via CHAOS with CHAOS-MAIL id 54912; Wed 3-Sep-86 21:58:28 EDT
Date: Wed, 3 Sep 86 21:57 EDT
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: Documentation strings and function.
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA, Rice@SUMEX-AIM
In-Reply-To: <FAHLMAN.12236108178.BABYL@C.CS.CMU.EDU>
Message-ID: <860903215722.4.KMP@EMU.SCRC.Symbolics.COM>
Although I would not argue in favor of such an interpretation, I think you'd
have a tough time arguing that the restriction on p67 refers to anything other
than functions defined by DEFUN.
Both the description of DEFUN on p67 (which you cite) and the description of
LAMBDA on p60 (which you don't comment on) use the same confusing syntax
description:
...
{declaration | documentation-string}*
...
Well, ok, they don't. p60 refers to documentation-string and p67 refers to a
doc-string. (-: Maybe only a doc-string is constrained the way you suggest but
a documentation-string is not. :-)
[On an unrelated issue that I noticed on the same page, p67 should clearly
say that
(DEFUN name lambda-list {declaration|doc-string}* {form}*)
causes the symbol NAME to be a global name for the function specified by
the lambda expression
(LAMBDA lambda-list {declaration|doc-string}* (BLOCK name {form}*))
Otherwise, the ability of RETURN-FROM to work in a DEFUN seems just a little
too magical, and suggests that LAMBDA or DEFUN somehow interacts with RETURN-FROM
in some strange way that we don't ever explain.]
Anyway, I think that multiple doc strings should not be undefined and that we
should relax that restriction. They would be especially to people (like myself)
who get grossed out by The Indentation Problem as illustrated in:
(DEFUN FOO (X Y)
"This is a very long documentation string which when printed out
seems to have an obscure amount of indentation on its second and
third line even though it looked nicely lined up in the source."
...)
or:
(DEFUN FOO (X Y)
"This is a very long documentation string which when printed out
has no problem about indentation for the subsequent lines, but when
viewed in the source looks pretty yucky."
...)
I'd prefer:
(DEFUN FOO (X Y)
"This is how we might allow a very long documentation string to be"
"typed in in order to let it look good in the source and also to"
"let it look good when obtained later, perhaps as a single string with"
"newlines inserted between each of the pieces.")
This would also be handy for defmacro, since you could prefix or postfix
documentation strings in the expansion without worrying about whether the
user was also going to supply a documentation string that elaborated on
the standardly provided documentation.
∂04-Sep-86 0739 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Documentation strings and function.
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 4 Sep 86 07:39:21 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9425; Thu 4-Sep-86 10:37:15 EDT
Date: Thu, 4 Sep 86 10:37 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Documentation strings and function.
To: James Rice <Rice@SUMEX-AIM.ARPA>,
Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
Common-Lisp@SU-AI.ARPA
In-Reply-To: <12236040169.57.RICE@SUMEX-AIM.ARPA>,
<FAHLMAN.12236108178.BABYL@C.CS.CMU.EDU>,
<860903215722.4.KMP@EMU.SCRC.Symbolics.COM>
Message-ID: <860904103704.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
When I brought up the multiple-doc-string issue when we were discussing
parse-body, everybody seemed unanimous that the current book intended
that the first string was the only doc string and that subsequent
strings were part of the executable body (and therefore declarations
after the second string were an error).
Anyway, I was then and am willing to continue believing multiple doc
strings should be OK, though I don't have strong enough opinions to take
sides. If multiple doc strings are allowed, what does parse-body (if we
ever decide on what that should be and do) return? Should it return a
list of the doc strings (in the order encountered)? Should it return
one string with newlines between the individual strings? What does
(documentation 'foo 'defun) return? A list of strings? One string with
newlines or some other separator?
∂04-Sep-86 0853 allen@bfly-vax.bbn.com Re: Documentation strings and function.
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 08:53:52 PDT
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
cc: James Rice <Rice@sumex-aim.ARPA>, Common-Lisp@su-ai.ARPA,
allen@bfly-vax.bbn.com
Subject: Re: Documentation strings and function.
In-reply-to: Your message of Wed, 3 Sep 1986 21:09 EDT.
<FAHLMAN.12236108178.BABYL@C.CS.CMU.EDU>
Date: 04 Sep 86 11:45:55 EDT (Thu)
From: allen@bfly-vax.bbn.com
Scott:
It would seem that "It is an error if more than one doc-string is present"
is inconsistent with the syntactic description of defun at the top of page 67.
I refer specifically to the {declaration | doc-string}* segment, which
implies a free mix of any number of declarations and doc-strings. Rice's
example is legal, if one relies on the latter. It should be decided which
is correct, and the appropriate repair made to the book.
/Don
∂04-Sep-86 0945 FAHLMAN@C.CS.CMU.EDU Documentation strings and function.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 09:45:47 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Sep 86 12:44:23-EDT
Date: Thu, 4 Sep 1986 12:44 EDT
Message-ID: <FAHLMAN.12236278321.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: allen@BFLY-VAX.BBN.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: Documentation strings and function.
In-reply-to: Msg of 4 Sep 1986 11:45-EDT from allen at bfly-vax.bbn.com
Well, there are things that are hard to express in the simple syntactic
notation Guy chose to use: exactly three of these things are allowed if
and only if one of those things is present, etc. I think that there are
several places in the book where the syntactic expressions provide some
necessary conditions, but where further restrictions on the format are
specified by the text.
In order to fix all of these things, so that the syntactic expressions
provide a necessary and sufficient formal grammar for the language, we
would have to go to a much more complex notation, which would be
much tougher on the average reader. I think that the current system,
where there are syntactic expressions that are sometimes further
restricted by English statements, is the way to go.
I agree that the statement forbidding multiple doc-strings should not be
as well-hidden as it currently is. The fact that people have missed it
is pretty good evidence that it is not visible enough.
-- Scott
∂04-Sep-86 1038 LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU Problems with Notation in CLtL
Received: from WISCVM.WISC.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 10:37:50 PDT
Received: from (LINNDR)VUENGVAX.BITNET by WISCVM.WISC.EDU on 09/04/86
at 12:37:07 CDT
Date: Thu, 4 Sep 86 12:27 CST
From: <LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU> (David Linn)
Subject: Problems with Notation in CLtL
To: Common-Lisp@SU-AI.ARPA
X-Original-To: Common-Lisp@SU-AI.ARPA, LINNDR
>Well, there are things that are hard to express in the simple syntactic
>notation Guy chose to use: exactly three of these things are allowed if
>and only if one of those things is present, etc. I think that there are
>several places in the book where the syntactic expressions provide some
>necessary conditions, but where further restrictions on the format are
>specified by the text.
>
>In order to fix all of these things, so that the syntactic expressions
>provide a necessary and sufficient formal grammar for the language, we
>would have to go to a much more complex notation, which would be
>much tougher on the average reader. I think that the current system,
>where there are syntactic expressions that are sometimes further
>restricted by English statements, is the way to go.
>
>I agree that the statement forbidding multiple doc-strings should not be
>as well-hidden as it currently is. The fact that people have missed it
>is pretty good evidence that it is not visible enough.
>
>-- Scott
>
-------------------------------------------------------------------------
Would it be appropriate to provide a second reference to clear up this
confusion? If sufficient notation would make CLtL impenetrable for the
average reader, could not a reference with sufficient notation be made
availble for those with the desire to wade through it?
David Linn
LINNDR@VUENGVAX.BITNET
LINNDR%VUEGNVAX.BITNET@WISCVM.WISC.EDU ! Internet (I think)
...!psuvax1!vuengvax.bitnet!linndr ! uucp/USENET
∂04-Sep-86 1102 allen@bfly-vax.bbn.com Re: Documentation strings and function.
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 11:02:48 PDT
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
cc: allen@bfly-vax.bbn.com, Common-Lisp@su-ai.ARPA
Subject: Re: Documentation strings and function.
In-reply-to: Your message of Thu, 4 Sep 1986 12:44 EDT.
<FAHLMAN.12236278321.BABYL@C.CS.CMU.EDU>
--------
Scott:
Date: 04 Sep 86 13:55:50 EDT (Thu)
From: allen@bfly-vax.bbn.com
It may be that there are aspects of the language that are hard or
impossible to express in Guy's simple notation. Since I think that
simplicity is a virtue, I would advocate retaining the notation and in
those cases where it is insufficient the description can be augmented
with (non-well-hidden) English.
For this case though, if we agree that the sentence midway thru pg 67
is The Truth, then how about
defun name lambda-list {declaration}* [doc-string] {declaration}* {form}*
/don
∂04-Sep-86 1222 FAHLMAN@C.CS.CMU.EDU Documentation strings and function.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 12:22:43 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Sep 86 15:21:09-EDT
Date: Thu, 4 Sep 1986 15:20 EDT
Message-ID: <FAHLMAN.12236306826.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: allen@BFLY-VAX.BBN.COM
Cc: Common-Lisp@SU-AI.ARPA
Subject: Documentation strings and function.
In-reply-to: Msg of 4 Sep 1986 13:55-EDT from allen at bfly-vax.bbn.com
defun name lambda-list {declaration}* [doc-string] {declaration}* {form}*
Yes, it looks like this is the right way to express things in this case.
-- Scott
∂04-Sep-86 1421 Bobrow.pa@Xerox.COM Re: Documentation strings and function.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 14:21:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 14:00:42 PDT
Date: 4 Sep 86 13:58 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Documentation strings and function.
In-reply-to: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>'s message
of Thu, 4 Sep 86 10:37 EDT
To: DCP@QUABBIN.SCRC.Symbolics.COM
cc: Rice@SUMEX-AIM.ARPA, Fahlman@C.CS.CMU.EDU,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <860904-140042-1593@Xerox>
If multiple doc strings are allowed, what does parse-body
(if we ever decide on what that should be and do) return?
A single string or a list of such, so that these are distinguished.
-- danny
∂04-Sep-86 1421 Bobrow.pa@Xerox.COM Re: Documentation strings and function.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Sep 86 14:20:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 SEP 86 14:00:40 PDT
Date: 4 Sep 86 13:56 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: Documentation strings and function.
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Thu,
4 Sep 86 12:44 EDT
To: Fahlman@C.CS.CMU.EDU
cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA
Message-ID: <860904-140040-1592@Xerox>
I think multiple document strings should be allowed. Perhaps all should
precede any declarations. The argument for multiple document strings is
that one can then use a simple parsing program to collect documentation
from code. One could imagine a convention of the first document string
describing the external interface or purpose of a document, and the
second information about the implementation. Why isn't the syntax
... lambda-list {documentation}* {declarations}* ...
-- danny
∂04-Sep-86 1518 @ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: Documentation strings and function.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 4 Sep 86 15:18:41 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 74511; 4 Sep 86 18:13:36 EDT
Date: Thu, 4 Sep 86 18:13 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Documentation strings and function.
To: Bobrow.pa@Xerox.COM, DCP@QUABBIN.SCRC.Symbolics.COM
cc: Rice@SUMEX-AIM.ARPA, Fahlman@C.CS.CMU.EDU,
KMP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860904-140042-1593@Xerox>
Message-ID: <860904181314.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 4 Sep 86 13:58 PDT
From: Bobrow.pa@Xerox.COM
If multiple doc strings are allowed, what does parse-body
(if we ever decide on what that should be and do) return?
A single string or a list of such, so that these are distinguished.
I would prefer that the result would always (SATISFY LISTP). This would
let macros do
,@doc-strings
instead of
,@(if (stringp doc-strings) `(,doc-strings) doc-strings)
as well as what DOCUMENTATION returns. I think this is the case where
optimizing a singleton list to be its single component does more harm
than good.
∂04-Sep-86 1639 @ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: Documentation strings and function.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 4 Sep 86 16:39:30 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 74534; 4 Sep 86 18:37:16 EDT
Date: Thu, 4 Sep 86 18:36 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Documentation strings and function.
To: Bobrow.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860904-140040-1592@Xerox>
Message-ID: <860904183653.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Personally, I usually put the documentation strings after the
declarations. One also has to consider macros expanding into both
documentation strings (is this really allowed?) as well as declarations.
The "simple parsing program" you allude to has been proposed under the
name of PARSE-BODY, but partly with my flaming seems to have been
stalled in committee.
∂04-Sep-86 1842 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU Re: Documentation strings and function.
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 86 18:42:26 PDT
Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 1445; Thu 4-Sep-86 21:43:56 EDT
Date: Thu, 4 Sep 86 21:43 EDT
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: Re: Documentation strings and function.
To: Bobrow.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: allen@BFLY-VAX.BBN.COM, Common-Lisp@SU-AI.ARPA
In-Reply-To: <860904-140040-1592@Xerox>
Message-ID: <860904214328.1.CFRY@JONES.AI.MIT.EDU>
Expressing the current CL syntax is complicated because the syntax is unnecessarily flexible.
Let's decide on whether the first doc string should be before or after the declarations
and change the spec to reflect that.
I think multiple document strings should be allowed. Perhaps all should
precede any declarations. The argument for multiple document strings is
that one can then use a simple parsing program to collect documentation
from code. One could imagine a convention of the first document string
describing the external interface or purpose of a document, and the
second information about the implementation. Why isn't the syntax
... lambda-list {documentation}* {declarations}* ...
I've yanked in Bobrow's statement since I think he has basically the right idea.
Here's an example of the format that I use:
(defun foo (a b) "this is THE doc string. It's used for describing the functionality of
this function as seen by the outside world."
(declare ...)
(declare ...)
(some code)
"this is a programmer comment. I use it to say things like,
FIX UP this code someday, or this algorhythm is too slow."
(some code)
"maybe another programmer comment"
(final code))
The function DOCUMENTTION returns the top doc string.
My own function PROGRAMMER-COMMENTS returns a list of
strings. In the above example it would return the 2nd and 3rd strings
in the body. The programmer-comments above don't violate existing CL semantics.
And a clever compiler will just throw them out.
The restriction on programmer-comments is that they do not include the
first string in the body and do not include the last form in the body if that happens
to be a string. The flexibility of whether doc strings or declarations go first
or intermingle is unncessarily confusing for both human and machine.
I find being able to imbed programer-comments in a definition and have a program that
can find them helps me make notes to myself in code. Frequently you know something is
not working well but can't fix it at the moment. Having a convenient way to store
the information which a machine can get at and tell you about it when you ask
is a great reminder.
∂05-Sep-86 1236 gls@Think.COM Problems with Notation in CLtL
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Sep 86 12:35:22 PDT
Received: from katherine by Godot.Think.COM via CHAOS; Fri, 5 Sep 86 15:31:51 edt
Date: Fri, 5 Sep 86 15:32 EDT
From: Guy Steele <gls@Think.COM>
Subject: Problems with Notation in CLtL
To: LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU, Common-Lisp@SU-AI.ARPA
Cc: gls@AQUINAS
In-Reply-To: <8609041739.AA09293@Zarathustra.Think.COM>
Message-Id: <860905153241.6.GLS@KATHERINE.THINK.COM>
Date: Thu, 4 Sep 86 12:27 CST
From: <LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU> (David Linn)
Would it be appropriate to provide a second reference to clear up this
confusion? If sufficient notation would make CLtL impenetrable for the
average reader, could not a reference with sufficient notation be made
availble for those with the desire to wade through it?
The construction of an accurate if impenetrable reference for CLtL is
merely "a small matter of writing". Sounds like a job for ANSI X3J13.
Any volunteers? The first meeting, as has already been announced on this
mailing list, is in Washington D.C. on September 23-24. Be there or
be square.
--Guy
∂05-Sep-86 2358 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Programmer Notes
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Sep 86 23:58:43 PDT
Received: from umass-cs by csnet-relay.csnet id bl04873; 6 Sep 86 2:27 EDT
Date: Fri, 5 Sep 86 19:40 EST
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: Programmer Notes
X-VMS-To: CSNET%"Common-Lisp@SU-AI.arpa"
When I want to leave a note to myself I include a comment with (...) in it.
This can easilly be found by a program (EMACS/ZWEI) and then I am
even in context where I can do something about it. Along this line,
I have often wanted to make the symbol ... be a special symbol which can
always be read, but whose evaluation always signals an error. In NIL
the symbol ... causes the compiler to bomb, so you can't use it to
indicate unimplemented functions (GJC!). I think that LISPMs can read
that symbol and do reasonable things with it. (Make it a special.)
I think that one documentation string is enough, the rest can be
ignored by any sufficiently smart compiler given the semantics of the
language, and anyone who builds a really nice Commmon Lisp environment
is welcome to extend the notion of documentation strings to include
multiple ones.
Most people are, I think, under the impression that documentation strings
can only be supplied once per function and so multiple documentatoin
strings are, de facto, a change to Common Lisp. This is a very unimportant
kind of thing to worry about, and I suggest it isn't worth it. I don't
care one way or the other, except that I think we need to have a standard.
A much more important issue is to define a syntactic standard for these kind
of things. There are several places in CLtL where it is suggested that
some entity fit into a sentence-schema in a certain way. I think that these
guidlines should be made strict requirements, and I think that a good
sentence-schema for documentation strings would be appropriate.
...Now back to important things, like message passing and declaration
scoping=>
∂07-Sep-86 1646 KMP@ELEPHANT-BUTTE.SCRC.Symbolics.COM #+FOO:BAR
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 7 Sep 86 16:46:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75402; Sat 6-Sep-86 16:42:35 EDT
Date: Sat, 6 Sep 86 16:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: #+FOO:BAR
To: Common-Lisp@SU-AI.ARPA
Message-ID: <860906164226.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
We need to rule on whether people can say:
#+FOO:BAR
#+(AND FOO:BAR ...)
if FOO is a potentially non-existent package and/or BAR is a
potentially non-exported symbol. My feeling is that in both
cases, these should be treated as "failing" features but should
not signal read errors.
There are other things that should be resolved about #+/#-, too.
Such as what package it defaultly reads in, whether there are any
standard features we can all agree on which should be in some known
package, etc.
∂08-Sep-86 0909 @ELEPHANT-BUTTE.SCRC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Programmer Notes
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 8 Sep 86 09:09:20 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by ELEPHANT-BUTTE.SCRC.Symbolics.COM via INTERNET with SMTP id 76279; 8 Sep 86 11:58:01 EDT
Date: Mon, 8 Sep 86 11:57 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Programmer Notes
To: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 5 Sep 86 20:40 EDT from ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
Message-ID: <860908115735.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Re: ... try using ---, since CLtL has forbidden (unquoted) symbols
consisting soley of dots.
I think it is a VERY BAD idea to encourage "really nice CL envirnoment"
to extend the concept of documentation strings to multiple documentation
strings. That is encouraging >gratuitous< incompatibility. We should
decide what we want and make the description and the prose match the
decision.
∂11-Sep-86 0839 MATT@LL.ARPA
Received: from LL.ARPA by SAIL.STANFORD.EDU with TCP; 11 Sep 86 08:39:06 PDT
Date: Thu 11 Sep 1986 11:36:59 EDT
From: <MATT@LL.ARPA>
Subject:
To: COMMON-LISP@SU-AI
Message-ID: <MATT.25441758@LL.ARPA>
Hi,
Please add me to your common lisp mailing list. Thanx.
Matt Stillerman
∂12-Sep-86 0311 bradley@Think.COM An example of where setf does not do what I want.
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 12 Sep 86 03:11:37 PDT
Received: by Godot.Think.COM; Fri, 12 Sep 86 06:11:05 edt
Message-Id: <8609121011.AA17090@Godot.Think.COM>
To: common-lisp@godot
Subject: An example of where setf does not do what I want.
Date: 12 Sep 86 06:11:02 EDT (Fri)
From: Bradley C. Kuszmaul <bradley@Think.COM>
I want to do
(setf (apply #'aref (cons my-array dims)) value)
where MY-ARRAY, DIMS, and VALUE are bound to meaningful values
Unfortunately, my reading of SETF says that the above won't work.
If I had (ASET value array &rest dims) then I could to
(apply #'aset (list* value my-array dims))
to do what I want.
How do I do what I want?
-Brad
∂12-Sep-86 0814 FAHLMAN@C.CS.CMU.EDU An example of where setf does not do what I want.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Sep 86 08:14:32 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 12 Sep 86 11:13:15-EDT
Date: Fri, 12 Sep 1986 11:13 EDT
Message-ID: <FAHLMAN.12238358866.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Bradley C. Kuszmaul" <bradley@ZARATHUSTRA.THINK.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: An example of where setf does not do what I want.
In-reply-to: Msg of 12 Sep 1986 06:11-EDT from Bradley C. Kuszmaul <bradley at Think.COM>
The inclusion of APPLY as one of the cases handled by SETF (page 96)
was prompted by exactly the case you describe:
(setf (apply #'aref (cons my-array dims)) value)
As I recall, we considered saying that (setf (apply #'aref ...) ...)
was required to work one way or another, but went with this supposedly
more general form instead: in a SETF the first argument to APPLY must be any
function known to SETF whose internal setting function is of a certain
form.
Unfortunately, when all this got written into the manual, we neglected
to say explicitly that AREF was required to be one of those functions
that works in this context (though all the examples indicate that this
is what we had in mind). So technically, given the current wording of
the manual, it is legal for SETF of APPLY of AREF not to work. In my
opinion, any Lisp that takes advantage of this loophole is broken, and
the manual should be clarified to require that SETF of APPLY of AREF
must work as you would expect.
Unfortunately, the Spice Lisp code seems to be broken in exactly this
way at present. I thought we had put in a special check to handle
AREF years ago, but apparently the fix didn't take. Other
implementations may have caught this bug from us.
-- Scott
∂12-Sep-86 0844 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM An example of where setf does not do what I want.
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 12 Sep 86 08:43:32 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 11465; Fri 12-Sep-86 11:42:35 EDT
Date: Fri, 12 Sep 86 11:41 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: An example of where setf does not do what I want.
To: Bradley C. Kuszmaul <bradley@Think.COM>, common-lisp@SU-AI.ARPA
In-Reply-To: <8609121011.AA17090@Godot.Think.COM>
Message-ID: <860912114143.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 12 Sep 86 06:11:02 EDT (Fri)
From: Bradley C. Kuszmaul <bradley@Think.COM>
I want to do
(setf (apply #'aref (cons my-array dims)) value)
where MY-ARRAY, DIMS, and VALUE are bound to meaningful values
Unfortunately, my reading of SETF says that the above won't work.
If I had (ASET value array &rest dims) then I could to
(apply #'aset (list* value my-array dims))
to do what I want.
How do I do what I want?
Your code should work. First, you don't need to do that consing for
apply. The old Zetalisp APPLY only took 2 arguments, but Common Lisp
APPLY takes 2 or more (and is like Zetalisp lexpr-funcall).
Notice (in the Symbolics [7.0] implementation)
(setf (apply #'aref my-array dims) value)
=> (APPLY #'ZL:ASET VALUE MY-ARRAY DIMS)
and also
(setf (apply #'aref (cons my-array dims)) value)
=> (APPLY #'ZL:ASET VALUE (VALUES (CONS MY-ARRAY DIMS)))
To show order of evaluation is still correct:
(setf (apply #'aref (my-array) (dims)) (value))
=> (LET* ((#:G8656 (MY-ARRAY))
(#:G8657 (DIMS)))
NIL
(APPLY #'ZL:ASET (VALUES (VALUE)) #:G8656 #:G8657))
and
(setf (apply #'aref (cons (my-array) (dims))) (value))
=> (LET* ((#:G8659 (CONS (MY-ARRAY) (DIMS))))
NIL
(APPLY #'ZL:ASET (VALUES (VALUE)) #:G8659))
What "reading of SETF" are you using? Pages 96 and 97 explicitly
describe this situation and also use AREF as the example. What
implementation are you using and how does it expand (or fail to expand).
∂12-Sep-86 0942 fateman@renoir.Berkeley.EDU OPS-5 in Common Lisp
Received: from RENOIR.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 12 Sep 86 09:41:56 PDT
Received: by renoir.Berkeley.EDU (5.53/1.16)
id AA06052; Fri, 12 Sep 86 09:42:15 PDT
Date: Fri, 12 Sep 86 09:42:15 PDT
From: fateman@renoir.Berkeley.EDU (Richard Fateman)
Message-Id: <8609121642.AA06052@renoir.Berkeley.EDU>
To: common-lisp@Sail.Stanford.EDU
Subject: OPS-5 in Common Lisp
A student here has ported the OPS-5 code from Franz Lisp to Common Lisp.
If there are no objections from CMU, we are willing to send
this to requestors to whom we can send electronic mail.
We would like recipient to tell us about bugs (and fixes,
if possible) that they find.
I don't know if there is any other OPS-5/CL version around, but
if there is a comparably "public" version, I'd be glad to compare the
two and suppress ours if ours is inferior.
It might lend itself to some useful benchmarking.
∂12-Sep-86 1030 Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM An example of where setf does not do what I want.
Received: from [192.10.41.41] by SAIL.STANFORD.EDU with TCP; 12 Sep 86 10:29:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79588; Fri 12-Sep-86 13:27:28 EDT
Date: Fri, 12 Sep 86 13:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: An example of where setf does not do what I want.
To: Bradley C. Kuszmaul <bradley@Think.COM>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8609121011.AA17090@Godot.Think.COM>
Message-ID: <860912132726.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 12 Sep 86 06:11:02 EDT (Fri)
From: Bradley C. Kuszmaul <bradley@Think.COM>
I want to do
(setf (apply #'aref (cons my-array dims)) value)
where MY-ARRAY, DIMS, and VALUE are bound to meaningful values
Unfortunately, my reading of SETF says that the above won't work.
If I had (ASET value array &rest dims) then I could to
(apply #'aset (list* value my-array dims))
to do what I want.
Recall that APPLY in Common Lisp allows more than two arguments,
unlike APPLY in traditional languages such as Maclisp, Zetalisp,
and Lisp 1.5. Hence the expansion is
(APPLY #'aset VALUE (CONS MY-ARRAY DIMS))
where aset is not a standard Common Lisp function, but we all know
what it does.
∂13-Sep-86 1846 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Locally
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 13 Sep 86 18:42:46 PDT
Received: from umass-cs by csnet-relay.csnet id ap00376; 11 Sep 86 17:38 EDT
Date: Wed, 10 Sep 86 20:24 EDT
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: Locally
X-VMS-To: CSNET%"Common-Lisp@Su-Ai.arpa"
What does the form:
(locally (declare (special foo))
(let ((foo 3))
(print foo)))
do?
On P.156 it says that Locally "does not bind any variables and therefore
cannot be used meaningfully for declarations of variable bindings".
This would imply that the FOO bound by the LET is not affected by the
LOCALLY and that this form should be an error because the SPECIAL
reference to FOO in (print foo) is not bound by the lexical binding
of FOO.
In NIL, Vaxlisp and HPCommon Lisp this form executes smoothly and
prints "3". Either all three implementations are wrong, or
the documentation is confusing (to me.)
Personally I think that the implementations are correct, since
the other interpretation implies that the let in:
(locally (declare (special foo))
...
(let ((foo ...))
...))
Cannot ever be meaningfu, since the variable foo is REFERENCED as
a special, but bound as a lexical.
I think that Locally (declae (special foo)) should affect
every binding and reference to foo within the body of the locally.
This would make it behave like a lexically scoped version of "proclaim".
In any case the documentation seems ambiguous or wrong.
∂14-Sep-86 1337 FAHLMAN@C.CS.CMU.EDU Locally
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Sep 86 13:37:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 14 Sep 86 16:36:00-EDT
Date: Sun, 14 Sep 1986 16:35 EDT
Message-ID: <FAHLMAN.12238941924.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: ELIOT%cs.umass.edu@RELAY.CS.NET
Cc: Common-Lisp@SU-AI.ARPA
Subject: Locally
In-reply-to: Msg of 10 Sep 1986 20:24-EDT from ELIOT%cs.umass.edu at CSNET-RELAY.ARPA
(locally (declare (special foo))
(let ((foo 3))
(print foo)))
In NIL, Vaxlisp and HPCommon Lisp this form executes smoothly and
prints "3". Either all three implementations are wrong, or
the documentation is confusing (to me.)
...
I think that Locally (declae (special foo)) should affect
every binding and reference to foo within the body of the locally.
This would make it behave like a lexically scoped version of "proclaim".
I think that all three implementations are right, but not for the reason
you suspect. The binding of FOO within the LET is a lexical binding,
because the external special declaration has no effect on this binding.
This lexical binding is what the reference to FOO in the PRINT form
sees. This new binding shadows the SPECIAL declaration for references
lexically within the LET. See the example on page 158, which is almost
exactly the same case.
The current rules covering special declarations are strange, at best,
but I think the manual is reasonably clear, under the circumstances.
There is an example covering the case that confused you. I admit that
the example is a bit hard to follow...
-- Scott
∂14-Sep-86 1543 Gregor.pa@Xerox.COM Portable CommonLoops port liasons
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Sep 86 15:43:00 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 86 15:38:01 PDT
Date: Sun, 14 Sep 86 15:36 PDT
From: Gregor.pa@Xerox.COM
Subject: Portable CommonLoops port liasons
To: Common-Lisp@SU-AI.arpa
Message-ID: <860914153628.2.GREGOR@AVALON.XEROX-PARC>
Line-fold: no
I apologize for the wide distribution of this message.
For each of the Common Lisp developers, I am looking for a liason with
whom I can communicate about porting Portable CommonLoops (PCL) to their
Lisp.
In the past I have been able to do most of the implementation-specific
customizations myself. Now, in order to make PCL run faster, I expect
the customizations to become more elaborate, and I would like to have
someone who works on each of the Common Lisp implementations to ask
questions of etc.
Could a system implementor from each of the from each of the Common Lisp
implementation groups please send me a message.
Thanks.
P.S. I already have liasons for the following implementations:
Kyoto Common Lisp
Lucid
Symbolics
Xerox Common Lisp
-------
∂15-Sep-86 1357 fateman@renoir.Berkeley.EDU ops-5
Received: from RENOIR.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 15 Sep 86 13:57:22 PDT
Received: by renoir.Berkeley.EDU (5.53/1.16)
id AA22172; Sun, 14 Sep 86 17:08:23 PDT
Date: Sun, 14 Sep 86 17:08:23 PDT
From: fateman@renoir.Berkeley.EDU (Richard Fateman)
Message-Id: <8609150008.AA22172@renoir.Berkeley.EDU>
To: common-lisp@Sail.Stanford.EDU
Subject: ops-5
There turns out to be an ops5 in CL at CMU, in addition to
the one done here. A cursory inspection of the CMU one indicates
that the changes made were quite similar to those in our version.
Unless someone is desperate for a copy, I suggest holding off a
few weeks until we get a chance to more carefully
compare the two and perhaps put the best of both in one system.
Distribution in either case would be public domain.
∂15-Sep-86 1438 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: OPS-5 in Common Lisp
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 15 Sep 86 14:35:57 PDT
Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a006635; 13 Sep 86 19:19 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Sat, 13 Sep 86 19:20:10 -0100
Message-Id: <12876.8609131820@aiva.ed.ac.uk>
To: fateman@renoir.berkeley.edu
Subject: Re: OPS-5 in Common Lisp
Cc: common-lisp@su-ai.arpa
For what it's worth, I ported OPS-5 from Franz to CL a while ago but
haven't been sending it around because I didn't know what restrictions
applied (there is a copyright notice at the beginning).
My port wasn't meant to be very efficient because I wanted to use
techniques that would apply to arbitrary Franz programs without
my understanding how they worked. So, for example, rather than
eliminate the fexprs, I had an automatic way to define them as a
combination of a macro and a function.
Anyway, I would also be interested in knowing whether I can redistribute
this, as there is some demand for it in the UK.
I have run some benchmarks using things like the monkey and banana problem,
but I would be interested in better tests if anyone has some.
-- Jeff
∂15-Sep-86 1937 NGALL@G.BBN.COM defstruct slots' default-inits
Received: from BBNG.ARPA by SAIL.STANFORD.EDU with TCP; 15 Sep 86 19:37:14 PDT
Date: 15 Sep 1986 22:35-EDT
Sender: NGALL@G.BBN.COM
Subject: defstruct slots' default-inits
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]15-Sep-86 22:35:17.NGALL>
Is the following legal CL:
(defstruct foo
(a 1)
(b (+ a 2)))
Specifically, is the default-init form of a slot allowed to reference the
values of slots to its left (above)? In other words, is the above
defined by CL to be equivalent to
(defstruct (foo (:constructor make-foo (&key (a 1) (b (+ a 2)))))
a
b)
(assuming that &key was allowed in the lambda-list for a BOA
constructor)
The only hint that I can find that indicates that it is legal is on
page 309 (bottom): "It is as if the initialization forms were used as
init forms for the keyword parameters of the constructor function."
Is there a more direct statement about the interaction of default-init
forms and other slots? If not, there should be.
-- Nick
∂17-Sep-86 1044 tsf@theory.cs.cmu.edu Readtables and prin1
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86 10:44:08 PDT
Date: Wednesday, 17 September 1986 13:40:39 EDT
From: Timothy.Freeman@theory.cs.cmu.edu
To: common-lisp@su-ai.arpa
Subject: Readtables and prin1
Message-ID: <1986.9.17.17.29.57.Timothy.Freeman@theory.cs.cmu.edu>
When prin1 is used to print something out, should it look at the current
value of *readtable* and produce text that can be read in assuming that
readtable is in effect, or should it produce text that can be read in with
the standard readtable? The manual says the following about the
*print-escape* flag:
"When this flag is not nil, then an attempt is made to print an
expression in such a way that it can be read again to produce an equal
structure."
(page 370, near the bottom)
Maybe Common Lisp needs a *print-readtable* variable that is analogous to
the *print-base* variable.
∂17-Sep-86 1813 FAHLMAN@C.CS.CMU.EDU Readtables and prin1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86 18:13:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Sep 86 21:08:13-EDT
Date: Wed, 17 Sep 1986 21:07 EDT
Message-ID: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Timothy.Freeman@THEORY.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: Readtables and prin1
In-reply-to: Msg of 17 Sep 1986 13:40-EDT from Timothy.Freeman at theory.cs.cmu.edu
I think that the usual practice is to print things out so that they can
be read in using the standard readtable. It would be VERY difficult to
write code that can print out text for any user-modified readtable,
especially if the read-table contains macros.
-- Scott
∂17-Sep-86 1847 FAHLMAN@C.CS.CMU.EDU Readtables and prin1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Sep 86 18:13:24 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Sep 86 21:08:13-EDT
Date: Wed, 17 Sep 1986 21:07 EDT
Message-ID: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Timothy.Freeman@THEORY.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: Readtables and prin1
In-reply-to: Msg of 17 Sep 1986 13:40-EDT from Timothy.Freeman at theory.cs.cmu.edu
I think that the usual practice is to print things out so that they can
be read in using the standard readtable. It would be VERY difficult to
write code that can print out text for any user-modified readtable,
especially if the read-table contains macros.
-- Scott
∂17-Sep-86 2001 Moon@STONY-BROOK.SCRC.Symbolics.COM Readtables and prin1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Sep 86 20:01:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106638; Wed 17-Sep-86 22:59:46 EDT
Date: Wed, 17 Sep 86 23:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Readtables and prin1
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Timothy.Freeman@THEORY.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Message-ID: <860917230007.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 17 Sep 1986 21:07 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think that the usual practice is to print things out so that they can
be read in using the standard readtable. It would be VERY difficult to
write code that can print out text for any user-modified readtable,
especially if the read-table contains macros.
Many systems attempt to print things out so that they can be read in using
the current readtable. For example, the Symbolics system uses the current
readtable to determine where escape characters are required (feed the
symbol's name back through the readtable and see if you get the same thing).
I agree that it is very difficult to cope with arbitrary user modifications
to the readtable, especially with the readtable-modifying primitives provided
by Common Lisp, but on the other hand it's easy to cope with some common,
simple modifications such as changing exclamation point from a constituent
to a macro. Basing this on the current readtable rather than the standard
readtable gives the user more flexibility, but as Common Lisp is currently
defined it is up to each implementation to decide whether it wants to go
to this much care.
I think if we're going to be more specific than "an attempt is made to
print an expression in such a way that it can be read again", then it
is incumbent on us to define more specifically how to customize the
printer in the same way that the reader can be customized, e.g. changing
the parenthesis characters.
∂17-Sep-86 2216 @DIAMOND.S4CC.Symbolics.COM:DDYER@RIVERSIDE.SCRC.Symbolics.COM Readtables and prin1
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 17 Sep 86 22:16:31 PDT
Received: from WHITE.SWW.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12684; Thu 18-Sep-86 01:15:45 EDT
Received: from PURPLE.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 33202; Wed 17-Sep-86 22:09:12 PDT
Date: Wed, 17 Sep 86 21:54 PDT
From: DDYER@RIVERSIDE.SCRC.Symbolics.COM
Subject: Readtables and prin1
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Timothy.Freeman@THEORY.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Fcc: W:>ddyer>mail.sent
In-Reply-To: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Message-ID: <860917215432.5.DDYER@PURPLE.SWW.Symbolics.COM>
Date: Wed, 17 Sep 1986 21:07 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think that the usual practice is to print things out so that they can
be read in using the standard readtable. It would be VERY difficult to
write code that can print out text for any user-modified readtable,
especially if the read-table contains macros.
-- Scott
Gee, that's the way Interlisp has always done it. In Interlisp, all
print operations accept a readtable as an optional argument, which
determines how things are printed. All you have to do is pre-process
the readtable so you know which characters need to be slashified.
∂18-Sep-86 0701 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Re: Readtables and prin1
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86 07:01:08 PDT
Received: from UR-CASHEW.ARPA (UR-CASHEW.ARPA) by UR-ACORN.ARPA via INTERNET with SMTP id 34026; 18 Sep 86 10:00:17-EDT
Date: Thu, 18 Sep 86 10:00 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Re: Readtables and prin1
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
Fcc: ACORN:>miller>babyl.text
In-Reply-To: <FAHLMAN.12239777784.BABYL@C.CS.CMU.EDU>
Message-ID: <860918100035.2.MILLER@UR-CASHEW.ARPA>
Sender: miller@UR-ACORN.ARPA
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Moon: 7 minutes since the full moon.
Date: Wed, 17 Sep 1986 21:07 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I think that the usual practice is to print things out so that they can
be read in using the standard readtable. It would be VERY difficult to
write code that can print out text for any user-modified readtable,
especially if the read-table contains macros.
-- Scott
It may be hard, but I suspect necessary. Given the user is in some context, he
would expect his print function to work "so it can be read in again" which
implies in his current context. Having to change contexts just to enter forms
(which would then get into even more difficult problems about packaging, etc.
in the new context) is not in my opinion a good user interface.
Brad Miller
------
miller@rochester.arpa
miller@ur-acorn.arpa
∂18-Sep-86 1037 FAHLMAN@C.CS.CMU.EDU Readtables and prin1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:37:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 18 Sep 86 13:35:17-EDT
Date: Thu, 18 Sep 1986 13:35 EDT
Message-ID: <FAHLMAN.12239957598.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Readtables and prin1
In-reply-to: Msg of 18 Sep 1986 10:00-EDT from Brad Miller <miller at UR-ACORN.ARPA>
OK, apparently lots of systems peek at the current readtable in order to
see which characters need to be slashified (or vertical-barred) on
output. That's probably impossible to get right, if by "right" you mean
doing the minimal slashification that is necessary but no more.
However, it doesn't hurt to slashify extra characters if there is some
doubt. I'm not sure whether I think this is valuable or important, but
I won't argue against it.
I still think that requiring PRIN1 to perform correctly given any
arbitrary readtable is much too hard to make this a required part of the
language, and probably impossible. I'm not sure whether a half-assed
attempt to adapt to the current readtable is better than explicitly not
doing this at all. My inclination would be to require anyone using an
extensively hacked readtable to write his own matching printer.
-- Scott
∂18-Sep-86 1039 yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Re: OPS5 in Common Lisp
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:39:43 PDT
Received: from utokyo-relay by csnet-relay.csnet id ba05313; 18 Sep 86 1:40 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA09220; Sat, 13 Sep 86 14:15:23+0900
From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Sat, 13 Sep 86 13:22:58 jst
Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet)
id AA00467; Sat, 13 Sep 86 13:12:28+0900
Date: Sat, 13 Sep 86 13:12:28+0900
Message-Id: <8609130412.AA00467@kurims.kurims.kyoto-u.junet>
To: common-lisp%su-ai.arpa%u-tokyo.junet@CSNET-RELAY.ARPA
Subject: Re: OPS5 in Common Lisp
We also have OPS5 running on KCL. It is VPS2, an interpreter for OPS5,
copyrighted by C.Forgy in 1979, 1980, and 1981. The sources came from
Edinburgh AIAI, where Jeff ported VPS2 onto Spice Lisp. Just removing
the use of fexpr was enough to port it onto KCL.
-- Taiichi
∂18-Sep-86 1100 LOOSEMORE@UTAH-20.ARPA *applyhook* question
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86 10:59:00 PDT
Date: Thu 18 Sep 86 11:58:48-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: *applyhook* question
To: common-lisp@SU-AI.ARPA
Message-ID: <12239961893.17.LOOSEMORE@UTAH-20.ARPA>
CLtL says the apply hook function "takes three arguments, a function, a list
of arguments, and an environment". Three questions:
(1) Is the "function" argument already evaluated? There are no user
accessible functions for extracting its definition from the environment.
-------
∂18-Sep-86 1104 LOOSEMORE@UTAH-20.ARPA *applyhook* question (hopefully I'll get it right this time)
Received: from UTAH-20.ARPA by SAIL.STANFORD.EDU with TCP; 18 Sep 86 11:04:18 PDT
Date: Thu 18 Sep 86 12:04:06-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
Subject: *applyhook* question (hopefully I'll get it right this time)
To: common-lisp@SU-AI.ARPA
Message-ID: <12239962857.17.LOOSEMORE@UTAH-20.ARPA>
CLtL says the apply hook function "takes three arguments, a function, a list
of arguments, and an environment". Three questions:
(1) Is the "function" argument already evaluated? There are no user-
accessible functions for extracting its definition from the environment, so
I don't see how the hook function could make much use of an unevaluated
function.
(2) Are the arguments in the argument list argument already evaluated, or
is it the responsibility of the hook function to evaluate them before
applying the function?
(3) If both the "function" and "argument list" arguments are already
evaluated, what does the hook function need an environment for?
-Sandra
-------
∂18-Sep-86 1538 pyramid!bein@hplabs.HP.COM testing addresses ... please ignore
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 86 15:38:42 PDT
Received: by hplabs.HP.COM ; Thu, 18 Sep 86 15:37:41 pdt
Date: Thu, 18 Sep 86 15:12:46 PDT
From: pyramid!bein@hplabs.HP.COM (David Bein)
Message-Id: <8609182212.AA14499@pyramid>
Received: by pyramid (5.51/3.14)
id AA14499; Thu, 18 Sep 86 15:12:46 PDT
To: common-lisp@sail.stanford.edu
Subject: testing addresses ... please ignore
--David
∂19-Sep-86 1853 cross@afit-ab.ARPA please add my name
Received: from AFIT-AB.ARPA by SAIL.STANFORD.EDU with TCP; 19 Sep 86 18:53:19 PDT
Date: 19 Sep 1986 21:26-EDT
From: cross@wpafb-ab
To: ai-ed-request@sumex-aim, soft-eng-request@mit-xx, common-lisp@su-ai,
info-xlisp-request@cmu-cs-spice
Subject: please add my name
Please add me to the list. Thanks.
Steve Cross
AFIT/ENG, WPAFB OH 45433-6583
(513) 255-3576
∂20-Sep-86 1751 cross@afit-ab.ARPA xlisp query
Received: from AFIT-AB.ARPA by SAIL.STANFORD.EDU with TCP; 20 Sep 86 17:51:18 PDT
Date: 20 Sep 1986 20:46-EDT
From: cross@wpafb-afita
To: common-lisp@su-ai, ai-ed@sumex-aim
Subject: xlisp query
Would appreciate a pointer to where I could download the source code for
xlisp 1.6 and any demonstratable programs written in xlisp. I'm aware
of the stuff published in AI Expert and have downloaded it, but cannot
find the source code. Thanks in advance.
Steve Cross
∂22-Sep-86 1734 @RIVERSIDE.SCRC.Symbolics.COM,@BIS-ALICE-LIDDELL.DialNet.Symbolics.COM:Stever@BIS-ALICE-LIDDELL.BISCC.DIALNET.SYMBOLICS.COM " macro character
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 86 17:34:18 PDT
Received: from BIS-ALICE-LIDDELL.BISCC.Dialnet.Symbolics.Com (BIS-ALICE-LIDDELL.DialNet.Symbolics.COM) by RIVERSIDE.SCRC.Symbolics.COM via DIAL with SMTP id 60147; 22 Sep 86 20:26:49 EDT
Date: Mon, 22 Sep 86 16:24 EDT
From: Stephen Robbins <Stever@BIS-ALICE-LIDDELL.BISCC.Dialnet.Symbolics.Com>
Subject: " macro character
To: common-lisp%su-ai.arpa@SCRC-RIVERSIDE.DialNet.Symbolics.COM
Message-ID: <860922162454.3.STEVER@BIS-ALICE-LIDDELL.BISCC.Dialnet.Symbolics.Com>
Hi!
On page 347 of CLtL, it says that the double quote character
accumulates characters until another double quote is seen. "An
exception to this occurs if a \single escape/ character is seen; ..."
If I want to write my function which handles " in Common-Lisp itself,
how can my handler tell when a character it's read is a single escape
character? It would have to be able to look into the readtable. If
there are ways to look inside readtables, I've missed them...
Thanks!
Stever
∂22-Sep-86 1749 Moon@STONY-BROOK.SCRC.Symbolics.COM *applyhook* question (hopefully I'll get it right this time)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 86 17:48:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110259; Mon 22-Sep-86 20:47:24 EDT
Date: Mon, 22 Sep 86 20:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *applyhook* question (hopefully I'll get it right this time)
To: SANDRA <LOOSEMORE@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <12239962857.17.LOOSEMORE@UTAH-20.ARPA>
Message-ID: <860922204642.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu 18 Sep 86 12:04:06-MDT
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
I haven't seen any replies to this. I guess I can try to take a crack at it.
CLtL says the apply hook function "takes three arguments, a function, a list
of arguments, and an environment". Three questions:
(1) Is the "function" argument already evaluated? There are no user-
accessible functions for extracting its definition from the environment, so
I don't see how the hook function could make much use of an unevaluated
function.
(2) Are the arguments in the argument list argument already evaluated, or
is it the responsibility of the hook function to evaluate them before
applying the function?
The intent of this ("when a function is about to be applied to arguments",
CLtL p.322) is that the applyhook is called after everything has been evaluated.
(3) If both the "function" and "argument list" arguments are already
evaluated, what does the hook function need an environment for?
It's not for anything! Apparently this was discussed on the mailing list
long ago, because this comment appears in our source code:
;After discussion on the Common Lisp mailing list, the ENV for the apply hook
;is the environment in which the arguments have already been evaluated, not
;the environment of the function to be called, which is of course still inside
;its closure. Its completely inutile to have the environment as an argument here,
;but it's in the book so I'll accept it and ignore it.
I suspect this env is a mistake, although it's conceivable that it is a hook
for some kind of future feature.
∂23-Sep-86 0352 ma←jpf%ux63.bath.ac.uk@Cs.Ucl.AC.UK OPS-5
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 23 Sep 86 03:52:07 PDT
Received: from ux63.bath.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a012978; 22 Sep 86 15:14 BST
Date: 22 Sep 1986 11:14:06-GMT
To: common-lisp <@Cs.Ucl.AC.UK:common-lisp@su-ai.arpa>
Subject: OPS-5
From: ma←jpf%ux63.bath.ac.uk@Cs.Ucl.AC.UK
What is all the fuss about? We ported OPS-5 to the HP Bobcat Common LISP
in a very small time; even improved the thing on the way. Is there an
official port to Common Lisp? Why?
==John
∂24-Sep-86 1159 ACUFF@SUMEX-AIM.ARPA Re: Readtables and prin1
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86 11:59:35 PDT
Date: Wed 24 Sep 86 11:56:35-PDT
From: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Subject: Re: Readtables and prin1
To: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12239957598.BABYL@C.CS.CMU.EDU>
Message-ID: <12241545278.32.ACUFF@SUMEX-AIM.ARPA>
... My inclination would be to require anyone using an
extensively hacked readtable to write his own matching printer.
-- Scott
What do you mean by "extensively"?
-- Rich
-------
∂24-Sep-86 1932 FAHLMAN@C.CS.CMU.EDU Mailing list requests
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86 19:32:39 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 24 Sep 86 22:31:28-EDT
Date: Wed, 24 Sep 1986 22:31 EDT
Message-ID: <FAHLMAN.12241628079.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: Mailing list requests
Several people have recently written to me with requests to be taken off
the Common Lisp mailing list. This list is maintained and altered by
Dick Gabriel, RPG@SU-AI.
-- Scott
∂24-Sep-86 1943 FAHLMAN@C.CS.CMU.EDU Readtables and prin1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Sep 86 19:41:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 24 Sep 86 22:34:03-EDT
Date: Wed, 24 Sep 1986 22:33 EDT
Message-ID: <FAHLMAN.12241628544.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Richard Acuff <Acuff@SUMEX-AIM.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Readtables and prin1
In-reply-to: Msg of 24 Sep 1986 14:56-EDT from Richard Acuff <Acuff at SUMEX-AIM.ARPA>
... My inclination would be to require anyone using an
extensively hacked readtable to write his own matching printer.
What do you mean by "extensively"?
Hacked enough that you can't do what you want to do with what is
presently in Common Lisp.
-- Scott
∂25-Sep-86 0640 @MC.LCS.MIT.EDU:STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU Are strings adjustable arrays?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Sep 86 06:40:10 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 SEP 86 09:23:00 EDT
Date: Thu, 25 Sep 86 09:23:17 EDT
From: "Stephen E. Robbins" <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Subject: Are strings adjustable arrays?
To: common-lisp@SU-AI.ARPA
Message-ID: <[MX.LCS.MIT.EDU].949090.860925.STEVER>
I have an application that does a lot of string hacking. For
efficiency reasons, we'd like to mutate our strings rather than
creating new ones all the time. It seems like strings which are
adjustable arrays with fill pointers are what we want. I
gather from page 299 that, while strings MAY have fill pointers,
there is no mechanism for having them automatically created
that way.
Is that the intention, or is there actually some way to have
strings created with fill pointers?
Stever
∂25-Sep-86 1358 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Are strings adjustable arrays?
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 25 Sep 86 13:58:46 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14426; Thu 25-Sep-86 16:57:22 EDT
Date: Thu, 25 Sep 86 16:56 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Are strings adjustable arrays?
To: Stephen E. Robbins <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>,
common-lisp@SU-AI.ARPA
In-Reply-To: <[MX.LCS.MIT.EDU].949090.860925.STEVER>
Message-ID: <860925165650.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Thu, 25 Sep 86 09:23:17 EDT
From: "Stephen E. Robbins" <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
I have an application that does a lot of string hacking. For
efficiency reasons, we'd like to mutate our strings rather than
creating new ones all the time. It seems like strings which are
adjustable arrays with fill pointers are what we want. I
gather from page 299 that, while strings MAY have fill pointers,
there is no mechanism for having them automatically created
that way.
Is that the intention, or is there actually some way to have
strings created with fill pointers?
To get either fill-pointers or adjustability, you have to use
make-array. make-string is not enough.
(make-array <size>
:element-type 'string-char
:fill-pointer 0
:adjustable t)
∂25-Sep-86 1416 RPG Jim Meehan Comments
To: common-lisp@SAIL.STANFORD.EDU
Jim Meehan asked me to forward a remark he was unable to successfully
mail to Common-Lisp.
-rpg-
ps. Oh yeah, by the way, here it is:
Date: Thu, 18 Sep 86 13:24:42 edt
From: James R. Meehan <csi!meehan@UUCP>
To: common-lisp@su-ai.arpa
Subject: Ignoring the DOTIMES variable
CLtL doesn't say whether DOTIMES actually "uses" the loop-variable, as
opposed to its value, and this ambiguity causes problems with portable
code. If DOTIMES does use the loop-variable, then
(DOTIMES (I 10) (DECLARE (IGNORE I)) (FOO))
can cause the compiler to issue a warning, but if DOTIMES doesn't use
the loop-variable, then
(DOTIMES (I 10) (FOO))
can also cause the compiler to issue a warning.
Personally, I think DOTIMES shouldn't use the variable, so that
(DOTIMES (I 10) (DECLARE (IGNORE I)) (FOO))
would be the correct style. That is, it should behave as if it were
implemented this way, more or less:
(DEFMACRO DOTIMES ((VAR END &OPTIONAL FINAL) &BODY BODY)
(LET ((I (GENSYM)) (STOP (GENSYM)))
`(DO ((,I 0 (1+ ,I))
(,STOP ,END))
((>= ,I ,STOP) (LET ((,VAR ,I)) ,FINAL))
(LET ((,VAR ,I)) ,@BODY))))
[This may need some additional work for copying declarations in the
"final" code, via the proposed PARSE-BODY or whatever.]
I've seen several implementations where DOTIMES actually uses the
loop-variable, thus permitting horrors like using SETQ to change the
value of the loop-variable and therefore control the iterations. The
implementation above would prevent that.
∂26-Sep-86 0558 Dan@Think.COM Jim Meehan Comments
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 86 05:58:26 PDT
Received: from zachary by Godot.Think.COM via CHAOS; Fri, 26 Sep 86 08:58:14 edt
Date: Fri, 26 Sep 86 09:00 EDT
From: Dan Aronson <Dan@Think.COM>
Subject: Jim Meehan Comments
To: RPG@SAIL.STANFORD.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8609252118.AA00590@Zarathustra.Think.COM>
Message-Id: <860926090057.4.DAN@ZACHARY.THINK.COM>
Date: Thu, 18 Sep 86 13:24:42 edt
From: James R. Meehan <csi!meehan@UUCP>
CLtL doesn't say whether DOTIMES actually "uses" the loop-variable, as
opposed to its value, and this ambiguity causes problems with portable
code.
I've seen several implementations where DOTIMES actually uses the
loop-variable, thus permitting horrors like using SETQ to change the
value of the loop-variable and therefore control the iterations. The
implementation above would prevent that.
Oh yes it does, page 128 of CLtL says:
Altering the value of VAR in the body of the loop (by using SETQ, for
example) will have unpredictable, possibly implementation-dependent results.
A Common Lisp compiler may choose to issue a warning if such a variable
appears in a SETQ.
This clearly means that if you do things like SETQ then you are going to run
in to portability problems.
--Dan
∂29-Sep-86 1037 DALY@IBM.COM getting on the common lisp list
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 29 Sep 86 10:37:46 PDT
Date: 29 September 1986, 12:47:02 EDT
From: "Timothy P. Daly" <DALY@ibm.com>
To: common-lisp@su-ai.arpa
Message-Id: <092986.124703.daly@ibm.com>
Subject: getting on the common lisp list
Hi,
How can I get on the list to receive the common lisp discussion?
My address is DALY@IBM.COM.
∂03-Oct-86 1337 @MC.LCS.MIT.EDU:STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86 13:37:13 PDT
Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 OCT 86 16:37:12 EDT
Date: Fri, 3 Oct 86 16:36:39 EDT
From: "Stephen E. Robbins" <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: common-lisp@SU-AI.ARPA
Message-ID: <[MX.LCS.MIT.EDU].950779.861003.STEVER>
Hi!
I'm doing a fair amount of string hacking right now. A lot of
things involve comparing and manipulating substrings. I do most
of this via the :START and :END arguments on the string functions.
Symbolics Common Lisp blows up if you specify a :END which is
greater than the length of a string. It also signals an error
if you give a large :END to a subsequence extract with SUBSEQ.
I looked through CLtL, but couldn't find any mention of this
case. Is the result of extracting past the end of a subsequence
considered undefined?
Stever
∂03-Oct-86 1429 RAM@C.CS.CMU.EDU
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86 14:29:30 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Fri 3 Oct 86 17:27:26-EDT
Date: Fri, 3 Oct 1986 17:27 EDT
Message-ID: <RAM.12243932018.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Stephen E. Robbins" <STEVER%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
In-reply-to: Msg of 3 Oct 1986 16:36-EDT from Stephen E. Robbins <STEVER%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
Date: Friday, 3 October 1986 16:36-EDT
From: Stephen E. Robbins <STEVER%MX.LCS.MIT.EDU at MC.LCS.MIT.EDU>
...Is the result of extracting past the end of a subsequence
considered undefined?
Stever
Yes. Although it isn't explicitly stated when :END is discussed on
page 246, the discussion doesn't make any sense otherwise. One could
hypothesize a magical exception in the case where END is greater than
the length, but there is nothing in the manual to support such a
conclusion. There are many illegal things which are not explicitly
stated to be illegal in the manual.
Rob
∂03-Oct-86 1853 @REAGAN.AI.MIT.EDU:RDZ@AI.AI.MIT.EDU Printing DEFSTRUCTs
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86 18:53:28 PDT
Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 5075; Fri 3-Oct-86 21:53:47 EDT
Date: Fri, 3 Oct 86 21:53 EDT
From: Ramin Zabih <RDZ@AI.AI.MIT.EDU>
Subject: Printing DEFSTRUCTs
To: common-lisp@SU-AI.ARPA
Message-ID: <861003215337.4.RDZ@NULLSTELLENSATZ.AI.MIT.EDU>
The standard way of printing structures involves printing out all
the slots in #S notation. The Common Lisp manual requires that
structures print in this way unless the user specifies his own
printing function in his structure definition (page 370). I don't think
that this is a very useful way of printing structures, since a lot of
structures are circular, and even those that aren't tend to be large in
any program that isn't a toy.
I would prefer that the default way of printing structures be changed to
be more useful (for instance the way ZetaLisp DEFSTRUCTs used to print,
which was as "#<SHIP 7765321>"). A less-preferable solution would
involve a global variable that controls how structures default to
printing.
Ramin
∂03-Oct-86 2100 DT50@A.CS.CMU.EDU printing structures
Received: from A.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86 20:58:50 PDT
Date: 3 Oct 86 23:57 EDT
From: Dave.Touretzky@A.CS.CMU.EDU
To: common-lisp@SU-AI.ARPA
Subject: printing structures
I second Ramin Zabih's suggestion that the default way to print a structure
should be to NOT show its components. If Common Lisp has to specify a
default print convention, the #<SHIP 1234567> notation is a better choice.
The same problem shows up with closures: some implementations build
closures that are circular or, at the very least, long and and hairy. They
are a source of annoyance every time the user accidentally (or purposely)
tries to print one. Since the Common Lisp standard deliberately says
nothing about the representation of closures, maybe it shouldn't specify
how they are printed. But it should at least SUGGEST to implementors that
they should choose a printing convention doesn't screw the user by default,
i.e. by trying to print something huge or circular. I like the Lisp Machine
#<LEXICAL-CLOSURE 1234567> notation just fine.
-- Dave
∂04-Oct-86 0023 bader@spice.cs.cmu.edu Re: printing structures
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Oct 86 00:23:51 PDT
Date: Sat, 4 Oct 1986 02:28:46-EDT
From: Miles Bader <bader@spice.cs.cmu.edu>
Subject: Re: printing structures
To: common-lisp@SU-AI.ARPA
Message-ID: <BMS.528791326.bader@spice.cs.cmu.edu>
Of course, some people actually like to read in what they print. Why not
just give different values to *print-length*, *print-level* and
*print-circle* in your init file?
-Miles
∂04-Oct-86 1817 RWK@YUKON.SCRC.Symbolics.COM Re: printing structures
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 4 Oct 86 18:17:42 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 97828; Sat 4-Oct-86 21:15:41 EDT
Date: Sat, 4 Oct 86 21:16 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: printing structures
To: Miles Bader <bader@spice.cs.cmu.edu>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <BMS.528791326.bader@spice.cs.cmu.edu>
Message-ID: <861004211602.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Sat, 4 Oct 1986 02:28:46-EDT
From: Miles Bader <bader@spice.cs.cmu.edu>
Of course, some people actually like to read in what they print. Why not
just give different values to *print-length*, *print-level* and
*print-circle* in your init file?
-Miles
As Common Lisp is currently designed, this just breaks
programs that like to read in what they print.
We provide a macro, WITH-STANDARD-IO-ENVIRONMENT which
binds the I/O control variables to their standard values.
This provides a sorely needed decoupling between I/O
for inter-program communication and the user-interface.
It is far easier to wrap this one form around the
portion of your program which does I/O than it is to
figure out what variables it depends on, and bind each
of them. Even if you want a few non-standard bindings,
it's easier to start with the standard bindings and
rebind a few than to deal with each of them.
I >strongly< recommend this be adopted. Once it's
adopted, it's much easier to discuss changing
the default global bindings for the I/O control
variables to make the environment easier to use
interactively. Without it, we'll just get caught up
in the communications and compatibility issues.
∂05-Oct-86 2017 Masinter.pa@Xerox.COM Re: printing structures
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Oct 86 20:17:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 OCT 86 20:05:51 PDT
Date: 5 Oct 86 20:08 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: printing structures
In-reply-to: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>'s message of
Sat, 4 Oct 86 21:16 EDT
To: RWK@YUKON.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <861005-200551-3386@Xerox>
Separating out I/O for for inter-program communication and the
user-interface is a good idea, but your proposal puts the burden on
inter-program communication ("wrap this one form around the portion of
your program which does I/O.") rather than on the user interface.
Wouldn't it be simpler to suggest that implementors of a
"top-level-loop" might want to bind a separate I/O environment for
reading and printing (but not for execution)?
Back onto the original discussion: we added a variable *print-structure*
which controlled how structures were printed by the default structure
printer, in the same way that *print-array* controls array output. I'm
reluctant to propose additions to the language, but if one was wanted,
this seems like a logical choice.
∂05-Oct-86 2115 SOLEY@XX.LCS.MIT.EDU printing structures
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 86 21:15:32 PDT
Date: Mon, 6 Oct 1986 00:14 EDT
Message-ID: <SOLEY.12244530480.BABYL@XX.LCS.MIT.EDU>
From: SOLEY@XX.LCS.MIT.EDU
To: Dave.Touretzky@A.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: printing structures
In-reply-to: Msg of 3 Oct 1986 23:57-EDT from Dave.Touretzky at A.CS.CMU.EDU
Date: Friday, 3 October 1986 23:57-EDT
From: Dave.Touretzky at A.CS.CMU.EDU
I second Ramin Zabih's suggestion that the default way to print a structure
should be to NOT show its components. If Common Lisp has to specify a
default print convention, the #<SHIP 1234567> notation is a better choice.
I third the suggestion, and further suggest *print-structure* control
the action of the printer on structures (a la *print-array*), and default
to not show components.
These two are just general cases of "*print-readably*", so to speak;
perhaps we should generalize?
-- Richard Soley
∂05-Oct-86 2223 ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Printing Structures
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Oct 86 22:23:46 PDT
Received: from umass-cs by csnet-relay.csnet id ac02811; 6 Oct 86 1:08 EDT
Date: Sun, 5 Oct 86 09:33 EDT
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
To: Common-Lisp@SU-AI.ARPA
Subject: Printing Structures
X-VMS-To: CSNET%"Common-Lisp@Su-ai.arpa"
I do not want the default printing format for structures changed.
Symbolic's incorrect implementation of this has gotten me very upset.
The default syntax is good at the begining of an implementation, when
the data structures are being defined and you will be looking
closely at all of the details. Eventually, I always define print
functions for each defstruct. "Eventually" often means just before
I implement the functions to create circular links.
The default syntax is also good for teaching people about Lisp. It is much
easier to explain how to use structures when you can show people
exactly what is in them. It would be harder to convince people
that nothing magical is going on if`
if you had to define a print function while explaining it.
As for lexical closures, and other system defined objects which do
not behave well using the default syntax, nothing in CL should prevent
the implementation from giving these objects special syntax. The default
syntax applies to user defined structures.
One more point. The default syntax is also best for testing out new
Lisp features.
∂06-Oct-86 1045 DLW@ALDERAAN.SCRC.Symbolics.COM Printing Structures
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 6 Oct 86 10:45:04 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9317; Mon 6-Oct-86 13:43:14 EDT
Date: Mon, 6 Oct 86 13:48 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Printing Structures
To: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 5 Oct 86 09:33 EDT from ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
Message-ID: <861006134816.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sun, 5 Oct 86 09:33 EDT
From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA
I do not want the default printing format for structures changed.
Symbolic's incorrect implementation of this has gotten me very upset.
Just for the record, Symbolics's Release 7 (coming very soon) implements
this in accordance with the standard. In general, Release 7 has far
fewer variances with the CL spec than Release 6.
We also have a special variable, called *print-structure-contents*,
(default t, of course) that controls this behavior. That several
implementations have found it necessary to adopt extensions to provide
this ability suggests that the ability ought to be made part of the
common standard.
∂06-Oct-86 2103 RWK@YUKON.SCRC.Symbolics.COM Re: printing structures
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 6 Oct 86 21:03:30 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98732; Tue 7-Oct-86 00:01:02 EDT
Date: Tue, 7 Oct 86 00:01 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: printing structures
To: Masinter.pa@Xerox.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <861005-200551-3386@Xerox>
Message-ID: <861007000135.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: 5 Oct 86 20:08 PDT
From: Masinter.pa@Xerox.COM
Separating out I/O for for inter-program communication and the
user-interface is a good idea, but your proposal puts the burden on
inter-program communication ("wrap this one form around the portion of
your program which does I/O.") rather than on the user interface.
I claim that's where the burden belongs. Programs interact
with the user a lot more than they interact with other programs
via read/print. And these interactions happen in a myriad
unpredictable way (consider tracing, for example). The
user-interface is global, it's the inter-program I/O that's
localized, so that's why it gets the form wrapped around it.
Besides and every time programms communicate, you have to think about
whether what is being communicated can be communicated via read/print,
whether you need *print-circle*, etc, anyway.
Wouldn't it be simpler to suggest that implementors of a
"top-level-loop" might want to bind a separate I/O environment for
reading and printing (but not for execution)?
That doesn't solve the problem. It isn't just a matter of
printing the return values, it's error messages, messages from
the program, debugging, etc. etc.
Back onto the original discussion: we added a variable *print-structure*
We called ours *print-structure-contents*
which controlled how structures were printed by the default structure
printer, in the same way that *print-array* controls array output. I'm
reluctant to propose additions to the language, but if one was wanted,
this seems like a logical choice.
Indeed.
∂07-Oct-86 0917 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: printing structures
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 7 Oct 86 09:16:57 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 16849; Tue 7-Oct-86 12:15:13 EDT
Date: Tue, 7 Oct 86 12:14 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: printing structures
To: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>,
Masinter.pa@Xerox.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <861007000135.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <861007121449.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Tue, 7 Oct 86 00:01 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
...
Back onto the original discussion: we added a variable *print-structure*
We called ours *print-structure-contents*
Nit: SYMBOLICS-COMMON-LISP:*PRINT-STRUCTURE-CONTENTS*, (or
SCL:*PRINT-STRUCTURE-CONTENTS*) to be exact.
which controlled how structures were printed by the default structure
printer, in the same way that *print-array* controls array output. I'm
reluctant to propose additions to the language, but if one was wanted,
this seems like a logical choice.
Indeed.
Ditto. I set it to NIL in my init file for the same reasons other
implementations have provided this extension.
∂16-Oct-86 0123 KMP@STONY-BROOK.SCRC.Symbolics.COM DEFVAR
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 86 21:30:50 PDT
Received: from EMU.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134663; Thu 16-Oct-86 00:30:09 EDT
Date: Thu, 16 Oct 86 00:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFVAR
To: Common-Lisp@SU-AI.ARPA
Message-ID: <861016002852.8.KMP@EMU.SCRC.Symbolics.COM>
CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is
allowed to or intended to intialize FOO. For example, in Symbolics'
Common Lisp FOO is left unbound but in VAXLISP it is initialized to NIL.
The manual should state clearly whether an initialization occurs or be
more up front if an ambiguity is in fact intended.
∂16-Oct-86 0123 KMP@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 86 21:43:08 PDT
Received: from EMU.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134668; Thu 16-Oct-86 00:41:53 EDT
Date: Thu, 16 Oct 86 00:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY
To: Common-Lisp@SU-AI.ARPA
Message-ID: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM>
CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an
array that was not created with the :ADJUSTABLE option." This strikes me
as overly restrictive. Why don't we say that ADJUST-ARRAY always returns
an adjusted array and that the argument array will be modified only if
(ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than
the current specification for the DELETE function. The way to be sure you
were going to win would be to say:
(SETQ X (ADJUST-ARRAY X ...))
just as you would do
(SETQ X (DELETE ... X))
and in special cases you would know that you didn't have to do the SETQ.
Does anyone really feel strongly that erring is necessary here?
I have an application where this comes up and as nearly as I can tell,
I must now go and simulate the effect of ADJUST-ARRAY in order to create
an array to a new size and make sure it gets filled properly. It makes me
sad that I should have to do this when there's a function already that
comes so close to what I want.
∂16-Oct-86 1604 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86 16:00:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135094; Thu 16-Oct-86 13:23:35 EDT
Date: Thu, 16 Oct 86 13:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM>
Message-ID: <861016132226.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Oct 86 00:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an
array that was not created with the :ADJUSTABLE option." This strikes me
as overly restrictive. Why don't we say that ADJUST-ARRAY always returns
an adjusted array and that the argument array will be modified only if
(ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than
the current specification for the DELETE function.
I suspect people rely on arrays as updatable objects with identity a lot more
often than they rely on lists that way. In other words, if ADJUST-ARRAY
sometimes quietly returns a new array and leaves the old one unadjusted,
there are likely to be other references to the old array that don't get
updated, and hence there will be bugs.
I always argued for making all arrays adjustable, for this reason. Given
that we can't have that, I think your behavior is reasonable but it should
not be the default because it could lead to undetected bugs.
I have an application where this comes up and as nearly as I can tell,
I must now go and simulate the effect of ADJUST-ARRAY in order to create
an array to a new size and make sure it gets filled properly. It makes me
sad that I should have to do this when there's a function already that
comes so close to what I want.
This is a good argument. This is a typical example of where Common Lisp went
wrong by standardizing a new, untried idea instead of standardizing current
practice, which would be okay except that what was standardized was a bundle
of several primitives and the underlying primitives were not exposed, so that
users can't easily define functions to hide the deficiencies they feel are
present in the standardized bundle.
I think there should be a new keyword argument to ADJUST-ARRAY that does
what you want, or else a separate function for this purpose, as there
was in Zetalisp (ARRAY-GROW). I don't think the default behavior of
ADJUST-ARRAY should be changed, for reasons given above. I can't think
of any good names for the keyword argument; the best I was able to come
up with was :IF-NOT-ADJUSTABLE with values :ERROR and :COPY.
∂16-Oct-86 1801 Moon@STONY-BROOK.SCRC.Symbolics.COM ADJUST-ARRAY
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86 18:01:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135094; Thu 16-Oct-86 13:23:35 EDT
Date: Thu, 16 Oct 86 13:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM>
Message-ID: <861016132226.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Oct 86 00:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an
array that was not created with the :ADJUSTABLE option." This strikes me
as overly restrictive. Why don't we say that ADJUST-ARRAY always returns
an adjusted array and that the argument array will be modified only if
(ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than
the current specification for the DELETE function.
I suspect people rely on arrays as updatable objects with identity a lot more
often than they rely on lists that way. In other words, if ADJUST-ARRAY
sometimes quietly returns a new array and leaves the old one unadjusted,
there are likely to be other references to the old array that don't get
updated, and hence there will be bugs.
I always argued for making all arrays adjustable, for this reason. Given
that we can't have that, I think your behavior is reasonable but it should
not be the default because it could lead to undetected bugs.
I have an application where this comes up and as nearly as I can tell,
I must now go and simulate the effect of ADJUST-ARRAY in order to create
an array to a new size and make sure it gets filled properly. It makes me
sad that I should have to do this when there's a function already that
comes so close to what I want.
This is a good argument. This is a typical example of where Common Lisp went
wrong by standardizing a new, untried idea instead of standardizing current
practice, which would be okay except that what was standardized was a bundle
of several primitives and the underlying primitives were not exposed, so that
users can't easily define functions to hide the deficiencies they feel are
present in the standardized bundle.
I think there should be a new keyword argument to ADJUST-ARRAY that does
what you want, or else a separate function for this purpose, as there
was in Zetalisp (ARRAY-GROW). I don't think the default behavior of
ADJUST-ARRAY should be changed, for reasons given above. I can't think
of any good names for the keyword argument; the best I was able to come
up with was :IF-NOT-ADJUSTABLE with values :ERROR and :COPY.
∂20-Oct-86 1046 FAHLMAN@C.CS.CMU.EDU DEFVAR
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 86 10:46:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 20 Oct 86 13:45:49-EDT
Date: Mon, 20 Oct 1986 13:45 EDT
Message-ID: <FAHLMAN.12248348124.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: DEFVAR
In-reply-to: Msg of 16 Oct 1986 00:28-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is
allowed to or intended to intialize FOO.
I believe that everyone's intent was that (DEFVAR FOO) should leave FOO
unbound. I would have sworn that the manual said this, but I guess it
doesn't.
Given that and the current syntax, there is the question of how the user
is supposed to supply a doc string for the variable if no initial
value is wanted. This was discussed in the past on one or two
occasions. I think the general feeling was that SETF of DOCUMENTAITON
was good enough in the rare case where this functionality is needed.
-- Scott
∂21-Oct-86 0851 @UR-ACORN.ARPA,@UR-CASHEW.ARPA:miller@UR-ACORN.ARPA Applying functions to all the symbols in a package...
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 21 Oct 86 08:50:50 PDT
Received: from UR-CASHEW.ARPA by UR-ACORN.ARPA via INTERNET with SMTP id 35577; 21 Oct 86 11:52:33-EDT
Date: Tue, 21 Oct 86 11:53 EDT
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Applying functions to all the symbols in a package...
To: common-lisp@SU-AI.ARPA
cc: miller@UR-ACORN.ARPA
Message-ID: <861021115308.3.MILLER@UR-CASHEW.ARPA>
Sender: miller@UR-ACORN.ARPA
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Moon: 3 days, 13 hours, 15 minutes since the full moon.
As a general rule, I find that as a style of coding, MAP and recursion are the
most clear, iteration much less so, and GO's the least so. I realize this may
be somewhat of a religious issue, so I won't go into why I despise iteration,
with the possible exception of array manipulation.
For this reason, I am somewhat surprised, that CL has iterative functions for
fiddling with all they symbols in a package (i.e. DO-SYMBOLS and
DO-EXTERNAL-SYMBOLS but no equivalent MAP forms (e.g. the zetalisp MAPATOMS
and MAPATOMS-ALL). This is particularly surprising in light of the fact that
almost every other MAP function has equivalent iterations forms, and
vice-versa.
I would like to suggest that such functions be added to the CL standard. I
believe the zetalisp functions mentioned above are sufficient, and provide a
clean user interface. This would be a downward compatible upgrade.
Brad Miller
------
miller@rochester.arpa
miller@ur-acorn.arpa
∂21-Oct-86 0913 FAHLMAN@C.CS.CMU.EDU Applying functions to all the symbols in a package...
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 86 09:13:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 21 Oct 86 12:12:19-EDT
Date: Tue, 21 Oct 1986 12:12 EDT
Message-ID: <FAHLMAN.12248593239.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Brad Miller <miller@UR-ACORN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Applying functions to all the symbols in a package...
In-reply-to: Msg of 21 Oct 1986 11:53-EDT from Brad Miller <miller at UR-ACORN.ARPA>
Back when the initial design was being done, we explicitly considered
whether to go with MAP-SYMBOLS or DO-SYMBOLS. At the time, it seemed
that most of us had the opposite religion from Mr. Miller. Most of us
favored the iterative form, and I don't remember anyone arguing for the
mapping form. A practical argument is that DO-SYMBOLS typically is used
in situations where there are a LOT of symbols must be processed, and in
the absence of a very clever compiler the MAP form would be slower due
to the need for explicitly calling the supplied functional argument.
I don't think that it would be worthwhile to include both forms just to
accommodate both stylistic preferences. These facilities are not used
often, so the occasional use of a less-favored style should not be a big
hardship for anyone. And, of course, fanatical DO-haters can write a
MAP-SYMBOLS macro easily enough, and not have to worry about what it
expands into.
-- Scott
∂30-Oct-86 1346 RPG Fahlman's remarks
∂28-Oct-86 0819 FAHLMAN@C.CS.CMU.EDU Fahlman's remarks
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86 08:18:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Oct 86 11:17:12-EST
Date: Tue, 28 Oct 1986 11:17 EST
Message-ID: <FAHLMAN.12250429124.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: willc%tekchips.tek.csnet@RELAY.CS.NET
Cc: Bobrow.pa@XEROX.COM, dlw@SCRC-STONY-BROOK.ARPA, gjs@AI.AI.MIT.EDU,
GLS@ZARATHUSTRA.THINK.COM, RPG@SU-AI.ARPA, scherlis@C.CS.CMU.EDU,
willc%tekchips.tek.com@RELAY.CS.NET, fahlman@C.CS.CMU.EDU
Subject: Fahlman's remarks
In-reply-to: Msg of 27 Oct 1986 15:38-EST from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA
Will,
As you noticed, my earlier post was biased -- I wasn't even trying to be
fair. Actually, I was hoping that by presenting the anti-change side of
the argument in an argumentative style, I would inspire someone to put
together the best possible case in favor of the change. I'd really like
to see that, and don't see a compelling case for making the change at
present. So, if you are tempted to add arguments in favor of the
change, please don't resist the temptation. I'd honestly like to see
what they are (besides the ones I listed).
A couple of serious rebuttals to your serious comments:
Macros have problems, but I can't accept the argument that people don't
use FLET and LABELS very often so it's ok to have a macro screw the few
who do.
Well, we differ in what we can accept, I guess. FLET and LABELS are in
Common Lisp over my objections. In all the Common Lisp code I've seen,
these things are practically never used, and in the rare cases when they
are used the user can take special care to avoid using macros with which
he is not personally familiar. So this hole in Common Lisp is
theoretical, and doesn't bother anyone with the good sense to avoid
using FLET and LABELS altogether. But the problem with macros and
merged names spaces is onmipresent and unavoidable. If we really feel
that the current situation is too treacherous to tolerate in the long
run, I would advocate removing FLET and LABELS rather than removing or
adding great hair to macros, which are used very heavily.
I would say that correct macros are hard to write, and always have been.
Incorrect macros are as easy to write as ever. It is certainly true that
bugs in macros are more likely to be discovered with a more uniform
semantics; in the real world, this is considered a good thing.
Again, the "incorrectness" at present is manifested only in a couple of
odd situations that most sensible programmers avoid. After the
namespace merger, the same kind of incorrectness can lead to nasty
hard-to-find problems in any part of your code, and the user must
therfore take great care to avoid such incorrectness. We don't have
good mechanisms for this at present. If we did, I'd feel a lot better
about this.
I don't understand why merging the namespaces would make it easier to
discover these bugs. Can you elaborate, beyond just saying that it
makes the semantics more uniform? Is it just that the merger tends to
insure that the bugs will come out and bite you rather than lying
dormant waiting for someone to do something dumb with an FLET?
It seems to me that Kohlbecker's recent thesis is the best extant
summary of the problems with Lisp macros and their proposed solutions.
I agree that Kohlbecker's solutions are not fully acceptable, but they
are better than anything I've seen coming out of the Common Lisp community.
Maybe we should wait until someone has a "fully acceptable" solution to
the macro problem to propose before we make changes that make the
effects of this problem much more serious for working programmers?
Until then, I'm much more comfortable with the situation in Common Lisp,
in which macros are quite useful and quite heavily used, despite the
theoretically dangerous interaction with FLET and LABELS.
In my view, the one significant argument against getting rid of the
function environment is the cost of converting existing code. This
is not an argument that is likely to carry much weight with someone
who has just begun to use Lisp or is thinking about using Lisp, and
I should hope that people now in that situation will form the majority
of users for any eventual Lisp standard. If not, the standard will
have failed.
True, but all users are not created equal. These new users will want to
build on the large body of software that exists in Common Lisp when they
take it up, not on the bare language itself. So the question is whether
the benfits of this change are worth chucking out all the software
accumulated so far and starting over, or at least spending a number of
high-quality man-years fixing old code and getting all the fixes to hang
together at once, instead of producing useful new programs. I'm not
saying that no change could ever be worth such an effort; I am wondering
whether THIS change is worth the effort at this time.
As a rule, if some change is going to come eventually, it is better to
take the hit now rather than later, since the total cost will be
smaller. However, a lot of companies and new users have finally been
drawn into Common Lisp by the promise of a widespread and stable
standard, and this might not not be a time in which to turn the Common
Lisp world upside down, especially if we can't explain what real
benefits this disruptive change will bring to the user community.
-- Scott
∂30-Oct-86 1346 RPG Fahlman's remarks
∂28-Oct-86 0922 gls@Think.COM Fahlman's remarks
Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Oct 86 09:22:07 PST
Received: by Zarathustra.Think.COM; Tue, 28 Oct 86 12:18:20 EST
Received: from valentine by Godot.Think.COM via CHAOS; Tue, 28 Oct 86 12:20:40 est
Date: Tue, 28 Oct 86 12:22 EST
From: Guy Steele <gls@Think.COM>
Subject: Fahlman's remarks
To: Fahlman@C.CS.CMU.EDU, willc%tekchips.tek.csnet@RELAY.CS.NET
Cc: Bobrow.pa@XEROX.COM, dlw@SCRC-STONY-BROOK.ARPA, gjs@AI.AI.MIT.EDU,
GLS@ZARATHUSTRA, RPG@SU-AI.ARPA, scherlis@C.CS.CMU.EDU,
willc%tekchips.tek.com@RELAY.CS.NET, gls@AQUINAS
In-Reply-To: <FAHLMAN.12250429124.BABYL@C.CS.CMU.EDU>
Message-Id: <861028122203.1.GLS@VALENTINE.THINK.COM>
I too would be grateful if Will should choose to draw up a more closely
reasoned set of arguments in favor of the namespace merger. (Maybe
bring it to the meeting, Will?)
I would like to caution Scott that while he has seen a great deal of
Common Lisp code, he has not seen it all. Neither have I, but I do know
that there is a substantial body of "working code" (read "code that some
company makes a lot of money from") that uses LABELS quite heavily and
with good reason. I don't think it is a simple matter of "nobody uses
LABELS, so let's just flush it", nor is it a matter of "anyone who uses
LABELS is a loser (not `sensible')"; just as it is not a simple matter
of "let's just merge the namespaces, because anyone who would be screwed
is a loser".
--Guy
∂30-Oct-86 1347 RPG Fahlman's remarks
∂28-Oct-86 1039 FAHLMAN@C.CS.CMU.EDU Fahlman's remarks
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Oct 86 10:39:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 28 Oct 86 13:38:31-EST
Date: Tue, 28 Oct 1986 13:38 EST
Message-ID: <FAHLMAN.12250454822.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: willc%tekchips.tek.csnet@RELAY.CS.NET, Bobrow.pa@XEROX.COM,
dlw@SCRC-STONY-BROOK.ARPA, gjs@AI.AI.MIT.EDU, GLS@ZARATHUSTRA.THINK.COM,
RPG@SU-AI.ARPA, scherlis@C.CS.CMU.EDU, fahlman@C.CS.CMU.EDU
Subject: Fahlman's remarks
In-reply-to: Msg of 27 Oct 1986 15:38-EST from willc%tekchips.tek.csnet at CSNET-RELAY.ARPA
Date: Tuesday, 28 October 1986 11:34-EST
From: Dick Gabriel <RPG at SAIL.STANFORD.EDU>
To: fahlman at C.CS.CMU.EDU
Re: FLET/LABELS
Scott, please forward this - I'm leaving for the airport right now.
In Lucid system code and in Lucid user's code we see *a lot*
of LABELS code. I would say that the use of FLET/LABELS has
taken off rather than being a curiosity.
-rpg-
∂30-Oct-86 1422 RPG Fahlman's remarks
∂27-Oct-86 2158 willc%tekchips.tek.csnet@CSNET-RELAY.ARPA Fahlman's remarks
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Oct 86 21:58:11 PST
Received: from tektronix by csnet-relay.csnet id ai11952; 27 Oct 86 18:02 EST
Received: by tektronix.TEK (5.31/6.16)
id AA12252; Mon, 27 Oct 86 12:36:42 PST
Received: by tekchips.TEK (5.31/6.16)
id AA07540; Mon, 27 Oct 86 12:38:52 PST
Message-Id: <8610272038.AA07540@tekchips.TEK>
To: RPG@SU-AI.ARPA, Bobrow.pa@XEROX.COM, dlw@SCRC-STONY-BROOK.ARPA,
gjs@AI.AI.MIT.EDU, GLS@ZARATHUSTRA.THINK.COM, scherlis@C.CS.CMU.EDU,
fahlman@C.CS.CMU.EDU
Cc: willc%tekchips.tek.com@CSNET-RELAY.ARPA
Subject: Fahlman's remarks
Date: 27 Oct 86 12:38:47 PST (Mon)
From: willc%tekchips.tek.csnet@CSNET-RELAY.ARPA
Fahlman listed four arguments in favor of getting rid of the separate
function environment, devoting one line to each and tainting each by a
begrudging parenthetical remark. For amusement (and balance), I have
edited his arguments against the change into that style.
I was tempted to add arguments in favor, but I resisted. Below the
edited arguments, however, I add a couple of serious observations.
----------------------------------------------------------------
ARGUMENTS IN FAVOR OF THE CHANGE:
Makes the language more elegant in the eyes of some.
* Simplifies compilers (a bit).
* Simplifies formal reasoning about programs (though the practical
importance of this is unclear at present).
* Making this move may be the cost of peace with the Eulisp group (or it
may encourage them to make additional demands).
* Brings Common Lisp somewhat closer to Scheme (though there are so many
other differences that this may not matter much).
ARGUMENTS AGAINST THE CHANGE:
* Statically typed variables help prevent mistakes (and make programming
less convenient).
* FUNCALL might be expensive so it ought to look expensive (but it ought
not to be).
* Existing implementations will have to change (future implementations
also if the change is merely put off).
* Existing user programs will have to be fixed (future programs also
if the change is merely put off).
* Complicates the link-table strategy (a bit).
* Fixing one problem might imply that we're going to do something about
the others (but we probably won't).
* Macros that insert free references to function variables won't work
(but they don't work even now, thanks to FLET and LABELS).
----------------------------------------------------------------
Macros have problems, but I can't accept the argument that people don't
use FLET and LABELS very often so it's ok to have a macro screw the few
who do. There is a solution, which is to give the macro writer a
mechanism for inserting direct references to procedures and other values
(as opposed to indirect references through a named variable) into the
expanded code. Fahlman objects that macros then become hard to write.
I would say that correct macros are hard to write, and always have been.
Incorrect macros are as easy to write as ever. It is certainly true that
bugs in macros are more likely to be discovered with a more uniform
semantics; in the real world, this is considered a good thing.
It seems to me that Kohlbecker's recent thesis is the best extant
summary of the problems with Lisp macros and their proposed solutions.
I agree that Kohlbecker's solutions are not fully acceptable, but they
are better than anything I've seen coming out of the Common Lisp community.
----------------------------------------------------------------
In my view, the one significant argument against getting rid of the
function environment is the cost of converting existing code. This
is not an argument that is likely to carry much weight with someone
who has just begun to use Lisp or is thinking about using Lisp, and
I should hope that people now in that situation will form the majority
of users for any eventual Lisp standard. If not, the standard will
have failed.
Peace, Will
∂31-Oct-86 1324 edsel!sunvalleymall!jlz@navajo.stanford.edu Call for Papers
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86 13:23:55 PST
Received: by navajo.stanford.edu; Fri, 31 Oct 86 13:22:27 PST
Received: from sunvalleymall.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA03857; Fri, 31 Oct 86 12:33:15 pst
Received: by sunvalleymall.edsel.uucp (1.1/SMI-3.0DEV3)
id AA09846; Fri, 31 Oct 86 12:34:05 PST
Date: Fri, 31 Oct 86 12:34:05 PST
From: edsel!sunvalleymall!jlz@navajo.stanford.edu (Jan Zubkoff)
Message-Id: <8610312034.AA09846@sunvalleymall.edsel.uucp>
To: navajo!Common-lisp%sail@navajo.stanford.edu
Cc: sunvalleymall!jlz@navajo.stanford.edu
Subject: Call for Papers
LISP AND SYMBOLIC COMPUTATION:
An International Journal
10/27/86
CALL FOR PAPERS
LISP AND SYMBOLIC COMPUTATION: An International Journal (LASC) is
a new journal published by Kluwer Academic Publishers. Richard
P. Gabriel, Lucid, Inc. and Guy L. Steele Jr., Thinking Machines,
Inc. are Editors-in-Chief.
The aim of this new journal is to present a forum for current and
evolving symbolic computing, focusing on LISP and
object-oriented programming. The scope includes:
* Programming language notations for symbolic computing
(e.g., data abstraction, parallelism, lazy evaluation,
infinite data objects, self-reference, message-passing,
generic functions, inheritance, encapsulation,
protection, metaobjects).
* Implementations and techniques (e.g., specialized
architectures, compiler design, combinatory models,
garbage collection, storage management, performance
analysis, smalltalks, flavors, common loops, etc.).
* Programming logics (e.g., semantics and reasoning about
programs, types and type inference).
* Programming environments and tools (e.g.,
Knowledge-based programming tools, program
transformations, specifications, debugging tools).
* Applications and experience with symbolic computing
(e.g., real-time programming, artificial intelligence
tools, experience with LISP, object-oriented
programming, window systems, user interfaces, operating
systems, parallel/distributed computing.
!
REQUIREMENTS FOR SUBMISSION
Timetable. Authors must submit five (5) complete copies of their papers.
Notice of acceptance or rejection will be sent to the first author.
Appearance. Each copy of the paper should be clearly legible.
Papers should be printed on 8-1/2 by 11" paper, double spaced
with at least 1 inch margins with no smaller than 12 pt. type.
Title Page. Each copy of the paper must have a title page (separate from
the body of the paper) containing the title of the paper, the names and
addresses of all the authors. The affiliation appearing under the author's
name should be the name of the organization for which the work was carried
out. When this is no longer the author's current affiliation, the latter
is given in the address footnote on the first page. The title page must
specify one topic from the scopes listed on the reverse side of this page.
Abstract. The abstract should be 150 to 200 words and should be short and
direct. It should be informative enough to serve as a substitute for
reading the paper itself. Work planned but not done should not be
described in the abstract. Do not display formulas and do not use citation
reference numbers.
Review Criteria. Each paper will be reviewed by experts in the area
specified from the scope as the topic of the paper. Acceptance will be
based on overall merit and significance of the reported research, as well
as the quality of the presentation.
Please send papers to:
Jan Zubkoff
Associate Editor, LASC
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@su-navajo
(415) 329-8400
Suggestions and inquiries to:
Dick Gabriel Guy L. Steele Jr.
Editor-in-Chief Editor-in-Chief
Lucid, Inc. Thinking Machines, Inc.
707 Laurel Street 245 First Street
Menlo Park, CA 94025 Cambridge, MA 02142
rpg@sail gls@think.COM
(415) 329-8400 (617) 876-1111
∂31-Oct-86 1923 JAR@AI.AI.MIT.EDU [KLOTZ: defstruct initialization in :constructor ]
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86 19:23:42 PST
Date: Fri, 31 Oct 86 22:25:47 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: [KLOTZ: defstruct initialization in :constructor ]
To: common-lisp@SU-AI.ARPA
Message-ID: <[AI.AI.MIT.EDU].113071.861031.JAR>
Parameter lists for :CONSTRUCTOR's should act as much as possible like
lambda lists. CLtL doesn't require this, but it seems like a good idea.
- Jonathan
Date: Thu, 2 Oct 86 20:31 EDT
From: Leigh L. Klotz <KLOTZ at OZ.AI.MIT.EDU>
To: pgslcd at AI.AI.MIT.EDU
cc: jar at AI.AI.MIT.EDU
Re: defstruct initialization in :constructor
Message-ID: <861002203146.1.KLOTZ@JOE-LOUIS.LCS.MIT.EDU>
(DEFSTRUCT (STATIC-VARIABLE-CACHE-ENTRY
(:CONSTRUCTOR MAKE-STATIC-VARIABLE-CACHE-ENTRY
(REAL-OBJECT &AUX
(VARIABLE (CAR REAL-OBJECT))
(UNIQUE-IDENTIFIER (CADR REAL-OBJECT)))))
VARIABLE
UNIQUE-IDENTIFIER
REAL-OBJECT)
The silver book doesn't explicitly say that the &aux's can depend on the
real args, but it does say that &aux was included to make all desirable
behaviors possible, and &aux forms in lambda can depend on the args.
...
∂03-Nov-86 0718 samalone@ATHENA.MIT.EDU DEFSTRUCT copier query
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86 07:18:31 PST
Received: by ATHENA (5.45/4.7)
id AA10177; Mon, 3 Nov 86 10:18:01 EST
From: <samalone@ATHENA.MIT.EDU>
Received: by ARES (5.45/4.7)
id AA20604; Mon, 3 Nov 86 10:17:13 EST
Date: Mon, 3 Nov 86 10:17:13 EST
Message-Id: <8611031517.AA20604@ARES>
To: common-lisp@sail.stanford.edu
Subject: DEFSTRUCT copier query
What is the defined behavior of the DEFSTRUCT-created copier function in the
face of :INCLUDEd types? For instance, given:
(defstruct bread
(state 'freshly-baked))
(defstruct (rye-bread (:include bread))
(seeded-p t))
is the result of evaluating:
(copy-bread (make-rye-bread :state 'stale :seeded-p nil))
A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL)
or
B: #S(BREAD :STATE STALE)
I am hoping that the correct answer is A. A function with behavior B can be
easily implemented in Common Lisp by any user who needs it, while a function
with behavior A cannot be without hardwiring all of the subtypes (recursively)
of the structure into the function, which seems like a harsh fate.
--Stuart A. Malone
∂03-Nov-86 0755 RAM@C.CS.CMU.EDU DEFSTRUCT copier query
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86 07:55:07 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 3 Nov 86 10:54:15-EST
Date: Mon, 3 Nov 1986 10:54 EST
Message-ID: <RAM.12251997821.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: <samalone@ATHENA.MIT.EDU>
Cc: common-lisp@SU-AI.ARPA
Subject: DEFSTRUCT copier query
In-reply-to: Msg of 3 Nov 1986 10:17-EST from <samalone at ATHENA.MIT.EDU>
Date: Monday, 3 November 1986 10:17-EST
From: <samalone at ATHENA.MIT.EDU>
Re: DEFSTRUCT copier query
(copy-bread (make-rye-bread :state 'stale :seeded-p nil))
A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL)
or
B: #S(BREAD :STATE STALE)
This unclarity has been pointed out before, but there didn't seem to
be any real consensus. I agree that it seems to be semantically
cleaner to return an object of the same type as the argument. I think
the only reasonable alternative would be to say that it is erronous.
Since there doesn't seem to be any support for B, no one can complain
if you implement A, although it may not be required for Common Lisp.
Rob
∂03-Nov-86 1338 Pavel.pa@Xerox.COM Re: DEFSTRUCT copier query
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 86 12:49:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 NOV 86 11:57:47 PST
Date: 3 Nov 86 11:57 PST
From: Pavel.pa@Xerox.COM
Subject: Re: DEFSTRUCT copier query
In-reply-to: Rob MacLachlan <RAM@C.CS.CMU.EDU>'s message of Mon, 3 Nov
86 10:54 EST
To: RAM@C.CS.CMU.EDU
cc: samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA
Message-ID: <861103-115747-5004@Xerox>
Date: Mon, 3 Nov 86 10:54 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Date: Monday, 3 November 1986 10:17-EST
From: <samalone at ATHENA.MIT.EDU>
(copy-bread (make-rye-bread :state 'stale :seeded-p nil))
A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL)
or
B: #S(BREAD :STATE STALE)
Since there doesn't seem to be any support for B, no one can
complain if you implement A, although it may not be required for
Common Lisp.
I can complain, and I would. I am strongly of the opinion that the
function COPY-BREAD here should always create a value of type BREAD, not
one of its subtypes. If you want to get the effect of A, let us create
a new function COPY that copies any Lisp value at all. It seems strange
to have several such functions, one for each section of the type space.
I claim that such a function, along with COPY-BREAD having semantics B
above, would provide all of the functionality desired in the cleanest
way.
Pavel
∂03-Nov-86 1937 Bobrow.pa@Xerox.COM Re: DEFSTRUCT copier query
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 86 19:36:48 PST
Received: from Salvador.ms by ArpaGateway.ms ; 03 NOV 86 18:14:13 PST
Date: 3 Nov 86 18:13 PST
Sender: Bobrow.pa@Xerox.COM
Subject: Re: DEFSTRUCT copier query
In-reply-to: Pavel.pa's message of 3 Nov 86 11:57 PST
To: Pavel.pa@Xerox.COM
cc: RAM@C.CS.CMU.EDU, samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Message-ID: <861103-181413-5511@Xerox>
Date: Mon, 3 Nov 86 10:54 EST From: Rob MacLachlan
<RAM@C.CS.CMU.EDU>
Date: Monday, 3 November 1986 10:17-EST From:
<samalone at ATHENA.MIT.EDU>
(copy-bread (make-rye-bread :state 'stale :seeded-p
nil))
A: #S(RYE-BREAD :STATE STALE :SEEDED-P
NIL) or
B: #S(BREAD :STATE STALE)
Since there doesn't seem to be any support for B, no
one can complain if you implement A, although it may not be
required for Common Lisp.
I can complain, and I would. I am strongly of the opinion that
the function COPY-BREAD here should always create a value of type
BREAD, not one of its subtypes. If you want to get the effect of
A, let us create a new function COPY that copies any Lisp value at
all. It seems strange to have several such functions, one for each
section of the type space. I claim that such a function, along with
COPY-BREAD having semantics B above, would provide all of the
functionality desired in the cleanest way.
Pavel
Within the new emerging Common Lisp Object Standard, COPY will be
specified as a generic function that copies its argument, producing an
instance of the same type. Functions such as copy-bread would be an
anomaly, but could mean what Pavel suggested.
-- danny
∂03-Nov-86 1938 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU DEFSTRUCT copier query
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86 19:38:42 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 15523; 3 Nov 86 22:37:26-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 43523; Mon 3-Nov-86 21:12:54-EST
Date: Mon, 3 Nov 86 22:13 est
Sender: mike@acorn
To: RAM@C.CS.CMU.EDU
From: mike%acorn@mit-live-oak.arpa
Subject: DEFSTRUCT copier query
Cc: samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA
Date: Mon, 3 Nov 1986 10:54 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Date: Monday, 3 November 1986 10:17-EST
From: <samalone at ATHENA.MIT.EDU>
Re: DEFSTRUCT copier query
(copy-bread (make-rye-bread :state 'stale :seeded-p nil))
A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL)
or
B: #S(BREAD :STATE STALE)
This unclarity has been pointed out before, but there didn't seem to
be any real consensus. I agree that it seems to be semantically
cleaner to return an object of the same type as the argument. I think
the only reasonable alternative would be to say that it is erronous.
Since there doesn't seem to be any support for B, no one can complain
if you implement A, although it may not be required for Common Lisp.
Rob
While we're at it, there are alot of problems with inheritance in
defstruct. Another is,
(defun (foo (:print-function (lambda ...)))
(defun (bar (:include foo)) slot1 slot2)
Now, does bar have a print function inherited from foo?
Clearly it can't inherit the constructor function from foo since
it doesn't have the same slots as foo, but the print function
is more at issue.
I think we should define :include to include only slots, and not any
other functions by options. If CommonLoops catches on, and if the
defstruct syntax is chosen, then we can specify the inheritance for
objects of class STRUCTURE to be only this, and you can use
a different class for inheriting other stuff.
....mike beckerle
Gold Hill Computers
∂06-Nov-86 2120 sridhar%tekchips.tek.csnet@RELAY.CS.NET Why is #'equalp not allowed in make-hash-table ?
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Nov 86 21:20:25 PST
Received: from tektronix by csnet-relay.csnet id aa05236; 6 Nov 86 15:46 EST
Received: by tektronix.TEK (5.31/6.16)
id AA12988; Thu, 6 Nov 86 11:43:04 PST
Received: by tekchips.TEK (5.31/6.16)
id AA13331; Thu, 6 Nov 86 11:43:11 PST
Message-Id: <8611061943.AA13331@tekchips.TEK>
To: common-lisp@SU-AI.ARPA
Subject: Why is #'equalp not allowed in make-hash-table ?
Date: 06 Nov 86 11:43:08 PST (Thu)
From: sridhar%tekchips.tek.csnet@RELAY.CS.NET
I want to create a hash table in which the keys are lisp objects
that satisfy #'equalp. CLtL does not allow #'equalp in :test
argument to make-hash-table. Why?
Specifically I cannot have vectors as key values.
For instance , how can you create a hash-table such that:
(setf (gethash (setq a (vector 1 2 3)) hash-table) 'foo)
(gethash a hash-table) => FOO T
(gethash (vector 1 2 3 ) hash-table) => FOO T.
--sridhar
∂07-Nov-86 1028 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM DEFVAR
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 7 Nov 86 10:14:45 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25906; Fri 7-Nov-86 13:12:59 EST
Date: Fri, 7 Nov 86 13:12 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: DEFVAR
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12248348124.BABYL@C.CS.CMU.EDU>
Message-ID: <861107131230.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Mon, 20 Oct 1986 13:45 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is
allowed to or intended to intialize FOO.
I believe that everyone's intent was that (DEFVAR FOO) should leave FOO
unbound. I would have sworn that the manual said this, but I guess it
doesn't.
Given that and the current syntax, there is the question of how the user
is supposed to supply a doc string for the variable if no initial
value is wanted. This was discussed in the past on one or two
occasions. I think the general feeling was that SETF of DOCUMENTAITON
was good enough in the rare case where this functionality is needed.
I personally preferred the
(defvar foo foo "foo's doc string")
suggestion since that is one declarative form instead of
(defvar foo)
(setf (documentation 'foo) "foo's doc string")
on the grounds that the latter is two forms, one declarative and one
procedural, and is more clumsy. It's not at all clear this is "rare".
∂08-Nov-86 1208 RPG Re: from Japan
∂08-Nov-86 0707 MATHIS@ADA20.ISI.EDU Re: from Japan
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 8 Nov 86 07:07:43 PST
Date: 8 Nov 1986 06:54-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: from Japan
From: MATHIS@ADA20.ISI.EDU
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
Cc: Mathis@ADA20.ISI.EDU, Fahlman@C.CS.CMU.EDU
Cc: rpg@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 8-Nov-86 06:54:19.MATHIS>
In-Reply-To: <8611041357.AA17427@ccut.u-tokyo.junet>
Idasan, Thank you for the message. I got it just before I was
leaving for the SC22 meeting in Vienna, Austria. I am glad you
hada chance to talk with Nakata. I don't know how things will
go, but I'll send out a message next weekend when Iget back. --
Bob Mathis
∂10-Nov-86 1921 Moon@STONY-BROOK.SCRC.Symbolics.COM Why is #'equalp not allowed in make-hash-table ?
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Nov 86 19:21:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 155303; Mon 10-Nov-86 22:19:54 EST
Date: Mon, 10 Nov 86 22:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Why is #'equalp not allowed in make-hash-table ?
To: sridhar%tekchips.tek.csnet@RELAY.CS.NET
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8611061943.AA13331@tekchips.TEK>
Message-ID: <861110221911.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 06 Nov 86 11:43:08 PST (Thu)
From: sridhar%tekchips.tek.csnet@RELAY.CS.NET
I want to create a hash table in which the keys are lisp objects
that satisfy #'equalp. CLtL does not allow #'equalp in :test
argument to make-hash-table. Why?
The :test argument to make-hash-table is not user-extensible because of
the nature of hashing. Each :test function has to have a corresponding
hashing function, which maps from an object to an integer that can be
used as an index into the hash table. These two functions have to be
consistent in the sense that for any two objects A and B, if the test
function returns true when applied to A and B, then the hash function
must return the same integer for both A and B.
Because Common Lisp didn't want to provide portable ways for users to
write hashing functions (in general this requires implementation
dependent knowledge to do a good job), Common Lisp doesn't allow
arbitrary predicates to be provided for the :test argument.
I think your suggestion that equalp be added to the set of allowed
predicates is a good one.
∂11-Nov-86 1220 edsel!bhopal!jonl@navajo.stanford.edu Why is #'equalp not allowed in make-hash-table ?
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 86 12:20:36 PST
Received: by navajo.stanford.edu; Tue, 11 Nov 86 12:17:26 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA03376; Fri, 7 Nov 86 11:17:31 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA06073; Fri, 7 Nov 86 11:16:24 PST
Date: Fri, 7 Nov 86 11:16:24 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8611071916.AA06073@bhopal.edsel.uucp>
To: navajo!sridhar%tekchips.tek.csnet%RELAY.CS.NET@navajo.stanford.edu
Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu
In-Reply-To: navajo!sridhar%tekchips.tek.csnet@RELAY.CS.NET's message of 06 Nov 86 11:43:08 PST (Thu)
Subject: Why is #'equalp not allowed in make-hash-table ?
About a year or so ago, there were two points about hash-tables receiving
heavy discussion:
1) Why not permit any predicate of two arguments as the :test argument
2) Why not permit explicit specification of the "sxhashing" function.
Several implementations, Lucid's included, have the capability of doing
(1) with no extra work. However, the question posed by (2) raises the
issue of consistency between the "numericalizing" function [i.e., whatever
you might use in place of sxhash] and the "equivalencing" function [i.e.,
whatever you might use in place of equal].
Although there didn't seem to be general consensus on the issue, the
proposal that seemed most consistent to me was:
(A) Extend Common Lisp hash-tables to permit any two-argument predicate
to be used as a :test function; and add an :sxhash argument which
specifies the function to reduce an s-expression into the integer
used in computing the collision chains (assuming you hash that way).
(B) The default for the :sxhash argument for EQ/EQL type tables can be
something internal (probably not documented or exported); the
default for any other :test argument will be #'equal.
This permits the extensions without having to address the issue of having
a function which computes the address of a pointer (for EQ/EQL tables).
Along that line I wonder why the default isn't :test = #'EQUAL, rather
than #'EQL? (or better yet, #'EQUALP). The EQ/EQL semantics is almost
never right when the table contains "complex" structures like lists,
vectors, defstructs and so on, and typically has unfortunate consequences
for relocating garbage collectors. Yet an EQUAL table can be just as
"speedy" as an EQ/EQL one when the entries aren't such "complex" entities;
so one should never try to switch semantics merely for "speed". This
doesn't say that there is no place for EQ/EQL tables -- merely that they
are often used for the wrong reasons.
-- JonL --
∂11-Nov-86 1300 @MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA Why is #'equalp not allowed in make-hash-table ?
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 86 12:59:53 PST
Received: from MIT-CHERRY.ARPA by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 16388; Tue 11-Nov-86 15:49:47-EST
Date: Tue, 11 Nov 86 15:50 EST
From: Soley@MIT-XX.ARPA
Subject: Why is #'equalp not allowed in make-hash-table ?
To: common-lisp@SU-AI.ARPA
In-Reply-To: <8611071916.AA06073@bhopal.edsel.uucp>
Message-ID: <861111155021.1.SOLEY@CHERRY.LCS.MIT.EDU>
Along that line I wonder why the default isn't :test = #'EQUAL, rather
than #'EQL?
For symmettry with ASSOC, MEMBER, DELETE, REMOVE, etc.
-- Richard
∂12-Nov-86 1435 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Declarations within FLET
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 86 14:34:58 PST
Date: Wed, 12 Nov 1986 17:34 EST
Message-ID: <STEVER.12254430013.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: Declarations within FLET
Is there any reason why declarations aren't permitted before the body
of an FLET? They ARE permitted before the body of a LET...
Stever
∂14-Nov-86 0955 AI.BOYER@MCC.COM sloop
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86 09:54:39 PST
Date: Fri, 14 Nov 1986 11:52 CST
Message-ID: <AI.BOYER.12254902958.BABYL@MCC.COM>
From: AI.BOYER@MCC.COM
To: common-lisp@su-ai
Subject: sloop
Bill Schelter has produced a lovely Common Lisp substitute
for the Maclisp/Zetalisp loop construct called sloop. It is
mostly upwards compatible with loop. This note describes
where to get it, what's new, etc. Fahlman observes that
any detailed discussion of the merits of this package
should be directed to the cl-iteration mailing list.
Sloop sources may be found in the file
<atp.schelter>sloop.lisp
on utexas-20.edu.
The code is free. It was written by Schelter from scratch
and is hence definitely free of any MIT or lisp machine
company copyright claim.
Like the original I.S.OPR facility in Interlisp, the sloop
construct permits the addition of new "collection" type
operators; for example, an averaging operation is defined.
A very general facility different from that of loop's has
been implemented to provide user extensible iteration paths.
One can map over tree fringes, Common Lisp hash tables, or
packages, e.g.
(sloop for sym in-package 'user when (fboundp sym) collect sym).
A "cross-product" concept has been added.
Instead of writing something like:
(loop for x in (l1) nconc (loop for y in (l2) collect (fn x y)))
one may write:
(sloop for x in (l1) sloop (for y in (l2) collect (fn x y)))
Only one "collection site" is created and used during
these two nested iterations.
Like the original loop, sloop takes advantage of locatives
to do collection more efficiently when they are available,
e.g., on MIT type lisp machines.
Sloop has been run in at least four dialects of Common Lisp
on three different kinds of machines.
I believe Schelter is definitely interested in reports of
bugs and suggestions for improvements. Mail will reach him
at atp.schelter@utexas-20.edu or at the Mathematics
Department, University of Texas at Austin, Austin, Texas
78712.
∂17-Nov-86 0218 z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET type-of
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Nov 86 02:18:18 PST
Received: from utokyo-relay by csnet-relay.csnet id ab05487; 17 Nov 86 5:12 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA04493; Mon, 17 Nov 86 18:10:46+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA16158; Mon, 17 Nov 86 18:06:12+0900
Date: Mon, 17 Nov 86 18:06:12+0900
From: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8611170906.AA16158@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: type-of
Is it absolutely impossible to define TYPE-OF more specific than
the current CLtL ?
I have been seen many problems derived from the underspecification of TYPE-OF.
As one of the users of PCL since Feb. on several different CommonLisp
implementation, I felt PCL might get more portability if TYPE-OF can be more defined.
I had sent a mail to several key persons about the possiblity of new definition of TYPE-OF,
but thier answers were pesimistic to do so.
The main reason of them is
'it is impossible or very hard to determine "the most-specific type"
among lots of CL implementations.'
I know there are many implementation designs and we cannot standardize it.
But, on the langauage specification level not on the hardware level,
we can define "the most specific type" of object according to 2.15 of CLtL.
Or 2.15 of CLtL should be updated to copy with TYPE-OF.
I had wrote a hierarchy chart based on 2.15.
which is attached on the japanese edition of CLtL.
Here is a brief sketch of it.
T>{pathname,stream,hash-table,readtable,package,random-state,
sequence,symbol,array,character,number}
sequence>{list,vector}
list>{cons,null}
symbol>{null}
array>{vector,simple-array}
vector>{string,bit-vector}
simple-array>{simple-string,simple-bit-array,simple-vector}
string>{simple-string}
bit-vector>{simple-bit-vector}
charcter>{string-char}
string-char>{standard-char}
number>{rational,float,complex}
rational>{integer,ratio}
integer>{fixnum,bignum}
float>{short-float,single-float,double-float,long-float}
where 'a>b' means 'a is the direct super of b, or b is just connected
to a as a direct subtype'
I tried to define 'terminal types'
terminal-types={pathname,stream,hash-table,readtable,package,
random-state,cons,null,simple-string,
simple-bit-vector,simple-vector,standard-char,fixnum,bignum,
ratio,short-float,single-float,double-float,long-float,complex}
terminal-types are types which do not appear on the left of the above '>'.
(keyword type was not appeared in 2.15, so keyword is not included here.)
Roughly, I imagine the value of TYPE-OF should be,
the symbol (not the list) of the most specific type among
terminal-types or higher types which are listed above or nil.
(do not permit the lower hardware dependent types)
'nil' is for undefined object, say unreadable objects.
I am writing an educational CommonLoops interpreter (the first version was
represented at the conf. of JSSST and IPSJ).
in it, I have a strong desire to get the firm definition of TYPE-OF.
I also have a suggestion from friends that
'there is a CLASS-OF in PCL'.
but CLASS-OF also need the detailed definition
on the built-in-classes.
If CLASS-OF is the right things to discuss,
I have no problem to shift the discussion to CLASS-OF.
Masayuki Ida
PS: there is no Ethernet-like link between US and Japan.
(though there is a firm link between us)
So, my response will be not timely. Sorry.
∂17-Nov-86 1503 RAM@C.CS.CMU.EDU type-of
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 86 15:03:51 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 17 Nov 86 18:03:28-EST
Date: Mon, 17 Nov 1986 18:03 EST
Message-ID: <RAM.12255745977.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: type-of
In-reply-to: Msg of Mon 17 Nov 86 18:06:12+0900 from Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
I think that your suggestion is contrary to the intent of the
specification. The "most specific" type can hardly ever be
represented by symbol, since there is almost always a more specific
type that does make use of a list type-specifier. Although it is
difficult to specify just how specific the type must be, it is clearly
a step in the wrong direction to require it to be a symbol.
It would also be wrong for NIL to be returned to indicate a random
object, since NIL is a meaningful type, but not one that any object
can posess. It would make more sense to return T or a new type such
as RANDOM.
I also have some doubts about the need to specify what Type-Of
returns. Could you demonstrate some code that needs to use Type-Of
and is adversely affected by different implementations? I suppose
that we could rigorously specify some function that does what you
want, but it shouldn't be Type-Of.
Rob
∂18-Nov-86 0812 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU Package functions not powerful enough?
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86 08:11:54 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2310; 18 Nov 86 11:12:21 EST
Date: Tue, 18 Nov 86 11:12 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Package functions not powerful enough?
To: CL@ACORN.CS.ROCHESTER.EDU
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <861118111222.3.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@ACORN.CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Hi all.
I'm having a problem, which I think revolves around the package funtions not
really being powerful enough to "do the job" correctly. Here is an instance
of the problem, since it is best illustrated by example:
Assume the packages FOO and BAR, where FOO is on BAR's USE list. Assume that
BAR has some symbol interned and marked as external, say 'frotz. The problem
is, that given this package layout is part of some program implementation
(i.e. not meant to be seen by the user) and the program wants to intern 'frotz
as an external symbol in FOO, so any other packages that USE FOO would see
this new definition. The program "knows" about 'frotz in BAR and wants BAR to
shadow it's own definition of 'frotz over FOO's. (in fact, we can even assume
it was interned with SHADOW).
The problem is that there is no way to export the symbol from FOO without
getting an error, because of the possible conflict with the symbol in BAR.
What I would like is some capability to supply an option to EXPORT, like
"export this symbol, and for any package there is a name conflict, make the
local symbol shadow the newly exported one" or vice versa, etc., rather than
makeing the user do it via the debugger.
The only extremely crufty solution to this problem with the existing tools
seems to be to unintern 'frotz from BAR, intern it in FOO, export it, then
SHADOW it in BAR. Since in a more realistic example the number of packages
'frotz could be in is potentially large, this doesn't seem to be the best of
plans, since each value of 'frotz must also be stored temporarily in the
interim.
To generalize the suggestion, I think that functions which have the
opportunity of creating name conflicts (as defined in section 11.5 CLtL)
should also allow the programmer to tell the system how they should be
resolved in advance. (This is an upwards compatible improvement: the
programmer need not give such "advice" and if none is given, the current
definition obtains.)
Brad Miller
PS: reply to miller@rochester.arpa, not the address in the header, it will
bounce.
------
miller@rochester.arpa
miller@ur-acorn.arpa
∂18-Nov-86 1058 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU [miller@UR-ACORN.ARPA: Package functions not powerful enough?]
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86 10:57:59 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2316; 18 Nov 86 13:57:59 EST
Date: Tue, 18 Nov 86 13:58 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: [miller@UR-ACORN.ARPA: Package functions not powerful enough?]
To: common-lisp@su-ai.stanford.edu
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <861118135804.5.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@ACORN.CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Sorry if this is the second time thru - it looked like it bounced the first
time.
%%%%Forwarded Message%%%%
From: Brad Miller <miller@UR-ACORN.ARPA>
Subject: Package functions not powerful enough?
To: common-lisp@su-ai.stanford.edu
Sender: miller@UR-ACORN.ARPA
Hi all.
I'm having a problem, which I think revolves around the package functions not
really being powerful enough to "do the job" correctly. Here is an instance
of the problem, since it is best illustrated by example:
Assume the packages FOO and BAR, where FOO is on BAR's USE list. Assume that
BAR has some symbol interned and marked as external, say 'frotz. The problem
is, that given this package layout is part of some program implementation
(i.e. not meant to be seen by the user) and the program wants to intern 'frotz
as an external symbol in FOO, so any other packages that USE FOO would see
this new definition. The program "knows" about 'frotz in BAR and wants BAR to
shadow it's own definition of 'frotz over FOO's. (in fact, we can even assume
it was interned with SHADOW).
The problem is that there is no way to export the symbol from FOO without
getting an error, because of the possible conflict with the symbol in BAR.
What I would like is some capability to supply an option to EXPORT, like
"export this symbol, and for any package there is a name conflict, make the
local symbol shadow the newly exported one" or vice versa, etc., rather than
makeing the user do it via the debugger.
The only extremely crufty solution to this problem with the existing tools
seems to be to unintern 'frotz from BAR, intern it in FOO, export it, then
SHADOW it in BAR. Since in a more realistic example the number of packages
'frotz could be in is potentially large, this doesn't seem to be the best of
plans, since each value of 'frotz must also be stored temporarily in the
interim.
To generalize the suggestion, I think that functions which have the
opportunity of creating name conflicts (as defined in section 11.5 CLtL)
should also allow the programmer to tell the system how they should be
resolved in advance. (This is an upwards compatible improvement: the
programmer need not give such "advice" and if none is given, the current
definition obtains.)
Brad Miller
PS: reply to miller@rochester.arpa, not the address in the header, it will
bounce.
------
miller@rochester.arpa
miller@ur-acorn.arpa
%%%%End Forwarded Message%%%%
------
miller@rochester.arpa
miller@ur-acorn.arpa
∂18-Nov-86 1257 wile@vaxa.isi.edu Packages: a modest solution.
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86 12:57:06 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA08142; Tue, 18 Nov 86 12:57:19 pst
Message-Id: <8611182057.AA08142@vaxa.isi.edu>
Date: 18 Nov 1986 1257-PST (Tuesday)
To: COMMON-LISP@SU-AI.ARPA
From: wile@ISI-VAXA
Subject: Packages: a modest solution.
Aha! I finally figured out the solution to the package problem!
I believe inclusion of packages is the worst mistake in Common LISP's
design. There isn't a day goes by (when I actually get to program or
debug) when I don't have package problems. Often, they dominate the
debugging time. I now type <pkg>::<symbol> all the time, just so I don't
have to think about whether the reader can figure out the right default. I
truly miss the days when a symbol was a symbol--surely one of the most
elegant features of Lisp 1.0 that's been lost.
But, of course, almost everyone feels this way. They just don't know how
to get around the problems packages seem to solve. Actually, I believe
that object-oriented programming generic functions solve about half the
problems packages are meant to solve; but they're not in Common LISP yet.
Everyone also realizes that the "mistake" is in tying package determination
to the reader. The reader simply has so little context that to determine
where a symbol belongs has to be done very stupidly. The solution
ultimately has to be a combination of the following:
* determining the appropriate package becomes trivial, unnecessary or
meaningless (keywords, generic functions, English commentary,
lexically scoped variables and functions(!), or symbols with
explicitly provided package names);
* more sophisticated programs determine the package after reading has
occurred (during a sort of "package expansion" phase); i.e., admit
that Lisp has a parser.
It is worth noting that the former category constitutes the bulk of the
symbols used in programs, and that getting these symbols in the "wrong"
package is the source of so much frustration and futility.
To move toward this future world, in which package determination becomes
decoupled from the reader, we simply need to make UNINTERNED symbol be the
MOST common symbol to be used. The reader must be able to be told not to
use default package. A solution might be to allow the read function to be
passed a package determiner function, as an optional (keyword) argument.
The determiner takes the result from read (uninterned symbols when no
package was explicitly given via : or :: and a symbol was read) and returns
the package expanded expression.
Notice, I am not assuming that reading a symbol is the only result of read.
In particular, the intelligent determination of packages comes from calling
the package determiner on S-expressions returned by the reader (full of
uninterned symbols and symbols with explicitly specified packages). I'm
not claiming that it will be easy to write such functions (if it were,
having the reader itself determine the package might be easy); I'm simply
claiming that it's worth it!
This must be defined carefully. At first blush, it may seem that the
reader should not invoke the package expander in a bottom up fashion. Only
the top level expression should be given to the expander. Then the
expander could be allowed to smash structure. This assumes no read macros
return previously defined structure (an invalid assumption, generally).
Alternatively, perhaps the expander should be called on every
sub-expression, with an extra argument indicating whether the top level
expression is being passed. Clearly, the reader should be able to assume
that if an uninterned symbol is determined to mean an interned symbol that
the uninterned symbol can be deleted if it just created it...
Present implementations of uninterned symbols cannot support this
determiner idea well. To support this, uninterned symbols should print out
very normally, perhaps in lower case without bars, instead of #:.... These
symbols should be full-fledged symbols with values and function cells.
Obviously, I am proposing that they not be syntactically distinguishable
from interned symbols. Should (MAKE-SYMBOL "a") be EQ to itself (it isn't
on Symbolics implementations). Is there any other way to create the
uninterned symbol with that name?
Comments?
Dave Wile
P.S. I am looking for conventions that make packages easier to live with.
Since I have converted code from an existing Interlisp implementation
in which all my global symbols were prefixed, I found using explicit
package prefixes on all exported symbols (for emphasis) whereever
they occur to be convenient. Naturally, I hid all the others and
dropped the prefix. Any other folklore on this?
∂18-Nov-86 1304 RWK@YUKON.SCRC.Symbolics.COM type-of
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86 13:04:32 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121418; Tue 18-Nov-86 16:02:39 EST
Date: Tue, 18 Nov 86 16:04 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: type-of
To: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
In-Reply-To: <8611170906.AA16158@ccut.u-tokyo.junet>
Message-ID: <861118160431.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
I'm considering writing a paper on the type system and the role of
SUBTYPEP. (I've been working on an extension of the type system for the
last year or so). Your question really relates to one of the core
issues of this topic.
I can think of a lot of analogies for TYPE-OF and SUBTYPEP,
and maybe I'll develop one of them for the paper, but they
all boil down to SELECTION of an object, and matching the
object with something which ACCEPTS objects. The exact
token which passes between the object and the acceptor of
objects doesn't matter, so long as the information is there!
Viewed in the abstract, it should be clear that the more
information this token has, the more flexibility the acceptor
has in deciding whether this object is suitable.
The tokens, of course, are the type specifiers. The
acceptor can be TYPE-CASE, CHECK-TYPE, or any function
which handles only a certain range of types. And SUBTYPEP/TYPEP
is what answers the question "is this object suitable."
Given this model, there is no such thing as "too specific"
an answer from TYPE-OF. On the contrary, the concern should
be with "not specific enough".
To address your specific points:
Date: Mon, 17 Nov 86 18:06:12+0900
From: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Is it absolutely impossible to define TYPE-OF more specific than
the current CLtL ?
I have been seen many problems derived from the underspecification of TYPE-OF.
As one of the users of PCL since Feb. on several different CommonLisp
implementation, I felt PCL might get more portability if TYPE-OF can be more defined.
TYPE-OF's >>lack<< of restriction is essential for
portability. It is SUBTYPEP which needs to be more
carefully defined.
I had sent a mail to several key persons about the possiblity of new definition of TYPE-OF,
but thier answers were pesimistic to do so.
The main reason of them is
'it is impossible or very hard to determine "the most-specific type"
among lots of CL implementations.'
It is wrong and impossible to define "the most-specific type".
What you want to specify is the "least-specific type". I.e.
we should specify that it must return a type *at least as specific as* X.
X is then the LEAST-SPECIFIC type which TYPE-OF may return; it may,
however, return something a good deal more specific. And it should,
if at all possible.
For example, TYPE-OF of a number must return one of INTEGER, COMPLEX, FLOAT,
RATIO, or one of their subtypes (if any), or some other subtype of NUMBER.
However, it is not good enough for it to return NUMBER.
However, it does not make sense to specify that TYPE-OF return one
of FIXNUM or BIGNUM, rather than INTEGER; a system which implemented
all numbers as "BIGNA" would be correct, if inefficient.
And a system might reasonably have two kinds of BIGNUM's, NEGATIVE-BIGNUM and
POSITIVE-BIGNUM. If you specify that TYPE-OF return just BIGNUM,
you prevent any program from distinguishing between them, when it
may be the program's advantage to make the distinction.
By over-specifying TYPE-OF, you can eliminate any implementation
flexibility or extensibility.
Along with this flexibility in what TYPE-OF returns goes a requirement
that SUBTYPEP know the answer when comparing the result of TYPE-OF and
whatever "least-specific type" that is specified. For example, if
TYPE-OF returns POWER-OF-TWO-POSITIVE-BIGNUM, SUBTYPEP must return
the values T T when asked if this is a subtype of BIGNUM, of INTEGER,
and of NUMBER.
SUBTYPEP is the only predicate provided for comparing types;
it goes without saying that any code that uses something else
like EQUAL will not be portable. Any type you get back from
TYPE-OF you must interpret with SUBTYPEP.
Here is an example of completely-portable code which depends on
TYPE-OF returning the MOST specific type.
(defun store-in-array-if-fits (object array &rest indicies)
(let ((object-type (type-of object))
(array-type (array-element-type array)))
(if (subtypep object-type array-type)
;; If the object fits, store it
(setf (apply #'aref array indicies) object)
;; Doesn't fit, so store 0 instead.
(setf (apply #'aref array indicies) 0))))
SUBTYPEP does explicitly the comparison that TYPEP does
implicitly when given an object and a type. For example,
when you write (TYPEP FOO 'BIGNUM) you don't have to worry
about whether the BIGNUM type is split into POWER-OF-TWO-BIGNUM
and NON-POWER-OF-TWO-BIGNUM's. Yet, a programmer writing
lower-level code can use the same primitive to distinguish
the two cases. For example:
(defun count-bits (integer)
(type-case integer
(fixnum (count-fixnum-bits integer))
;; Easy BIGNUM case
(positive-power-of-two-bignum 1)
;; All other BIGNUM's
(bignum (count-general-bignum-bits integer))))
This is the reason for the "most-specific" requirement in 2.15.
If I implement the type (ARRAY POSITIVE-POWER-OF-TWO-BIGNUM)
efficiently (by just storing the exponent), my first example continues
to work, so long as TYPE-OF returns the most-specific type.
If it instead just returned BIGNUM, as you propose, there
would be no way to write code which would decide whether this
particluar type of number will fit in this particular type
of array.
I know there are many implementation designs and we cannot standardize it.
But, on the langauage specification level not on the hardware level,
we can define "the most specific type" of object according to 2.15 of CLtL.
Or 2.15 of CLtL should be updated to copy with TYPE-OF.
I had wrote a hierarchy chart based on 2.15.
which is attached on the japanese edition of CLtL.
Here is a brief sketch of it.
The english version of CLtL would be clearer if it
included something like this.
T>{pathname,stream,hash-table,readtable,package,random-state,
sequence,symbol,array,character,number}
sequence>{list,vector}
list>{cons,null}
symbol>{null}
array>{vector,simple-array}
vector>{string,bit-vector}
simple-array>{simple-string,simple-bit-array,simple-vector}
string>{simple-string}
bit-vector>{simple-bit-vector}
charcter>{string-char}
string-char>{standard-char}
number>{rational,float,complex}
rational>{integer,ratio}
integer>{fixnum,bignum}
float>{short-float,single-float,double-float,long-float}
where 'a>b' means 'a is the direct super of b, or b is just connected
to a as a direct subtype'
I tried to define 'terminal types'
terminal-types={pathname,stream,hash-table,readtable,package,
random-state,cons,null,simple-string,
simple-bit-vector,simple-vector,standard-char,fixnum,bignum,
ratio,short-float,single-float,double-float,long-float,complex}
terminal-types are types which do not appear on the left of the above '>'.
(keyword type was not appeared in 2.15, so keyword is not included here.)
Roughly, I imagine the value of TYPE-OF should be,
the symbol (not the list) of the most specific type among
terminal-types or higher types which are listed above or nil.
(do not permit the lower hardware dependent types)
** REQUIRE ** the lower hardware dependent types.
'nil' is for undefined object, say unreadable objects.
No, not NIL. T would be a better choice here than NIL!
First, there are several kinds of unreadable objects
which already have types, such as COMPILED-FUNCTION.
Second, NIL is defined to be the *empty* type, that is *no*
objects are of type NIL. There is nothing wrong with having
an UNDEFINED type, however. NIL will be a subtype of
UNDEFINED, of course, and UNDEFINED will be a subtype of T.
I am writing an educational CommonLoops interpreter (the first version was
represented at the conf. of JSSST and IPSJ).
in it, I have a strong desire to get the firm definition of TYPE-OF.
More important is a firm definition of SUBTYPEP!
SUBTYPEP is the key to using the result of TYPE-OF.
I also have a suggestion from friends that
'there is a CLASS-OF in PCL'.
but CLASS-OF also need the detailed definition
on the built-in-classes.
If CLASS-OF is the right things to discuss,
I have no problem to shift the discussion to CLASS-OF.
CLASS-OF is not the issue here.
Masayuki Ida
PS: there is no Ethernet-like link between US and Japan.
(though there is a firm link between us)
So, my response will be not timely. Sorry.
∂18-Nov-86 1454 shebs%utah-orion@utah-cs.arpa Packages
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86 14:53:59 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA21982; Tue, 18 Nov 86 15:55:05 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA11049; Tue, 18 Nov 86 15:49:29 MST
Date: Tue, 18 Nov 86 15:49:29 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8611182249.AA11049@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Packages
I haven't found packages to be as much of a headache as some people on
this list. They were both a pain and a necessity for PCLS, because the
code is sort of half PSL and half CL, and many symbols of the same name
exist in both packages (the psl: and lisp: packages don't use each other).
User-type code (at least around here) tends to use packages sparingly -
a program doesn't get its own package until it has a fat user manual and
a community of users :-). As a consequence, adding the package operations
occurs late in development, after the program has stabilized somewhat.
Since there are no explicit package references in the source, there is a
strong inducement to avoid adding explicit internal symbol references
all over the place.
The package fixes that have been proposed seem to me like bandaids, and not
worth the effort. A *real* solution would promote environments to full
first-class objects, and provide some good protocols for operating on
them. Look to T for a first attempt, and to Eulisp for more concentrated
efforts to get it right. Somehow, I don't see it ever getting into the
present form of CL. (Strange how CL is starting to look a little dated
here and there...)
stan
∂18-Nov-86 1539 masinter.pa@Xerox.COM Re: type-of
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86 15:39:25 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 15:24:08 PST
Date: 18 Nov 86 15:24 PST
From: masinter.pa@Xerox.COM
Subject: Re: type-of
In-reply-to: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>'s message of
Tue, 18 Nov 86 16:04 EST
To: RWK@YUKON.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA
Message-ID: <861118-152408-2377@Xerox>
Here's a proposed level of specificity for type-of and subtypep which
would be an improvement:
Let Z be the set of "well-behaved" type specifiers. (To be listed).
Then, for all Z:
For all data X:
if (typep x Z) => (subtypep (type-of x) z)
This says that type-of has to return something specific enough that
subtypep can deal with it.
My candidate set of "well-behaved" subtypes are exactly those that are
required to be distinct in Common Lisp:
array, number, integer, complex, float, symbol, ratio, rational...
This (a) isn't hard (b) is probably implemented by most common lisps
anyway.
The exact set of types identified as "well-behaved" is debatable, but I
think it is wise to leave out any implementation dependent types,
(long-float vs short-float, fixnum vs bignum), all of the non-intrinsic
types (satisfies), or require the relation to be true of any types that
are hard to calculate (things like nested ands and ors).
There may be a more specific stringent specification of type-of and
subtypep that people want to adopt, but its hard to imagine something
*less* specific than this, yet this seems adequate for most of the
purposes I know of.
∂18-Nov-86 1854 Miller.pa@Xerox.COM Re: Packages: a modest solution.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86 18:51:52 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 18:07:06 PST
Date: 18 Nov 86 18:08 PST
Sender: Miller.pa@Xerox.COM
Subject: Re: Packages: a modest solution.
In-reply-to: wile@VAXA.ISI.EDU's message of 18 Nov 86 12:57 PST
(Tuesday)
To: wile@VAXA.ISI.EDU
cc: COMMON-LISP@SU-AI.ARPA
From: Mark S. Miller <Miller.pa@Xerox.COM>
Message-ID: <861118-180706-2579@Xerox>
Take a look at the T language. It has reified lexical environments.
Such reified environments (called LOCALEs) seem able to do all that's
valuable with packages, and are based on a clean scoping semantics.
Modularity can be understood in terms of the abstract language and not
its reader.
I believe that if LOCALEs were added to CommonLisp, then (after new
programmers grew up with it) packages would only be used for old code.
This change can probably be made in an upwards compatible fashion.
----- MarkM
∂18-Nov-86 1906 RAM@C.CS.CMU.EDU Package functions not powerful enough?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86 19:06:27 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 18 Nov 86 22:05:54-EST
Date: Tue, 18 Nov 1986 22:05 EST
Message-ID: <RAM.12256052258.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: miller@ROCHESTER.ARPA
cc: common-lisp@SU-AI.ARPA
Subject: Package functions not powerful enough?
Your message is pretty unclear, but I think that there are
adequate tools for explicitly resolving potential name conflicts. In
the CMU Common Lisp package code, all conflict resolution is done with
standard package functions, so it is clearly doable. Of course, as
you make arbitrarily complex changes to the namespace, the code to do
so becomes arbitrarily complex.
Although I am fairly sure that there is a simpler solution than the
one proposed, the cruftiness is a natural reflection of the mismatch
between what you want the package system to do and what it was meant
to do.
The big problems that I see users having with the package system are
due to their inaccurate models of the real semantics of the package
system. This is encouraged by the current language in CLTL. One of
the biggest misconceptions is that a symbol "belongs" to its home
package. In fact, the home package has no semantics other than
printing. A more fundamental problem is that the package system
manipulates names, whereas users (quite reasonably) thing in terms of
managing named objects.
Rob
∂18-Nov-86 1909 FAHLMAN@C.CS.CMU.EDU TYPE-OF
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86 19:09:35 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 18 Nov 86 22:09:06-EST
Date: Tue, 18 Nov 1986 22:09 EST
Message-ID: <FAHLMAN.12256052839.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: TYPE-OF
Before we start debating proposals to improve TYPE-OF, we should
probably try to figure out what we really want to accomplish. Then we
will have some goals against which to measure the various proposals.
Given that the Common Lisp type system is a lattice and not a simple
tree, TYPE-OF (originally known as "one-argument TYPEP") was considered
to be of very dubious value, and was almost dropped. It was kept in the
language for only one purpose: to provide users with a quick and dirty
way to examine various objects interactively to see what they are. For
this purpose, the current definition is exactly right: each
implementation should provide as detailed a description as it can manage
conveniently. This is non-portable, but given the purpose of this
function, portability is less valuable than getting as much information
to the user as possible.
CLTL (page 52-53) basically says that TYPE-OF is not meant to be used in
code, except in a few odd situations that are adequately handled by the
current definition.
I sounds to me like Ida and Masinter have in mind some use of TYPE-OF
within programs, and that such use is not adequately covered by TYPEP
and TYPE-CASE. It seems to me that the best way to make progress is to
first spell out this problem or problems, then decide whether TYPE-OF is
the right way to solve the problem (as opposed to inventing some new
form), and finally to think about how to change the definition of
TYPE-OF. If these problems arise in the context of CommonLoops, then
maybe CLASS-OF is the right form to use.
-- Scott
∂19-Nov-86 0749 shebs%utah-orion@utah-cs.arpa Re: type-of
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 19 Nov 86 07:49:39 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA00592; Wed, 19 Nov 86 08:50:46 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA14443; Wed, 19 Nov 86 08:19:15 MST
Date: Wed, 19 Nov 86 08:19:15 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8611191519.AA14443@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Re: type-of
If type-of is meant for interactive use, perhaps it should be moved to
the miscellaneous chapter. Also, make it a macro that doesn't evaluate
its argument :-) :-).
stan
∂19-Nov-86 0817 sandra%utah-orion@utah-cs.arpa type-of
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 19 Nov 86 08:17:05 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA01245; Wed, 19 Nov 86 09:18:12 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA14790; Wed, 19 Nov 86 09:11:01 MST
Date: Wed, 19 Nov 86 09:11:01 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8611191611.AA14790@utah-orion.ARPA>
Subject: type-of
To: common-lisp@su-ai.arpa
From: RWK@YUKON.SCRC.Symbolics.COM (Robert W. Kerns)
Date: 18 Nov 86 21:04:00 GMT
Here is an example of completely-portable code which depends on
TYPE-OF returning the MOST specific type.
(defun store-in-array-if-fits (object array &rest indicies)
(let ((object-type (type-of object))
(array-type (array-element-type array)))
(if (subtypep object-type array-type)
;; If the object fits, store it
(setf (apply #'aref array indicies) object)
;; Doesn't fit, so store 0 instead.
(setf (apply #'aref array indicies) 0))))
Sorry, I can't buy this motivation. All this example illustrates is that
there is a good reason for having the TYPEP function around.
As it happens, in PCLS, TYPE-OF does go through a considerable amount of
work to find the most specific type that it can. So, (TYPE-OF 0) returns
BIT, which is correct but largely useless. My "gut feeling" is that what
the user probably wants is either FIXNUM or INTEGER -- something which
indicates how the object is represented internally, or (in other words)
one of the set of types which CLtL says are disjoint.
I'll have to agree that TYPE-OF as defined now is pretty bogus. The only
place I've ever had reason to use TYPE-OF in real code was to get a type
to pass to COERCE or CONCATENATE, etc., when I wanted to ensure that two
objects were of the same type; for example, both lists or whatever. But
this is full of holes, too. For example,
(coerce '#(a b c) (type-of (list)))
may fail, depending on whether your favorite implementation thinks NIL is
of type NULL, LIST, or SYMBOL. I ended up writing a specialized function
to do what I wanted, without relying on TYPE-OF.
In short, I am not convinced that TYPE-OF would be particularly useful even
if its definition were firmed up more. If nobody has any good use for this
function, arguing over how it should behave is rather pointless.
-Sandra
-------
∂19-Nov-86 1132 DLW@ALDERAAN.SCRC.Symbolics.COM Packages
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 19 Nov 86 11:30:27 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22063; Wed 19-Nov-86 14:26:48 EST
Date: Wed, 19 Nov 86 14:28 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Packages
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8611182249.AA11049@utah-orion.ARPA>
Message-ID: <861119142829.4.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Tue, 18 Nov 86 15:49:29 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Somehow, I don't see it ever getting into the
present form of CL. (Strange how CL is starting to look a little dated
here and there...)
Certainly. CL is an attempt to unify and codify a set of dialects that existed
and were well-tested and understood as of a few years ago. The idea was to do
basic cleanups, resolve differences between similar dialects into one large
Common subset, and codify it and make it stable. That's what Common Lisp is all
about.
There are lots of exciting new ideas in Lisp that are being worked on, including
locales and a lot of other things. To take every good new idea as it comes
along, and "add it to" Common Lisp, will destroy the stabilty of the language and
the confidence of the users outside the inner circle of Lisp innovators. These
new ideas are great things, but the reaction to them should not be to "add them
to the standard". A standard is useless if it isn't extremely stable. Common
Lisp's purpose in life is to be a standard, and so stability is of paramount
importance. Experimentation and new ideas in Lisp should continue, I hope in
great quantity and strength, and there should always be new dialects. But it's
not necessary to first "add it to Common Lisp".
∂19-Nov-86 2254 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU Packages: a modest solution.
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Nov 86 22:54:25 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 17359; 20 Nov 86 01:43:49-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 44908; Wed 19-Nov-86 22:33:42-EST
Date: Wed, 19 Nov 86 23:09 est
Sender: mike@acorn
To: wile@ISI-VAXA
from: mike%acorn@mit-live-oak.arpa
Subject: Packages: a modest solution.
Cc: COMMON-LISP@SU-AI.ARPA
Date: 18 Nov 1986 1257-PST (Tuesday)
From: wile@ISI-VAXA
Aha! I finally figured out the solution to the package problem!
I believe inclusion of packages is the worst mistake in Common LISP's
design. There isn't a day goes by (when I actually get to program or
debug) when I don't have package problems. Often, they dominate the
debugging time. I now type <pkg>::<symbol> all the time, just so I don't
have to think about whether the reader can figure out the right default.
This seems like a problem to me, since you have no control over internal
and external names anymore. I have a similarly explicit approach, but
it preserves the internal/external symbol distinction:
The biggest problem with packages is lack of education about how to
avoid most of their pitfalls. I have found that if you avoid
use-package or the options for :use to in-package and relatives,
and you explicitly export and inport names, then package problems go
away. The only packages which should be used are those which define
the lisp language, i.e., lisp, but not SYS. This avoids most snafu's.
The rule of thumb is "don't use a package unless you personally know
every single exported symbol of that package and know that it doesn't
conflict with any name you are using." This means basically that you
should never use-package anything except package lisp. (even this
causes problems, since lisp is such a big language that people
frequently begin accidently redefining primitives like check-type,
assert, etc. in embedded language systems.....)
For example, we had a major problem with the function
sys:lambda-list, which is supposed to take a symbol and print the
lambda-list, and a bunch of code which uses an internal symbol
"lambda-list" just as a local lexical var. If you load the files in
the wrong order, you get a package problem. This is only since
package lisp uses package sys, an unfortunate situation that can't be
rectified easily. The solution was to make a moby export file which
is read before almost anything, but this is really a kludge. The
problem is really that lisp code has no business using the symbol
"lambda-list" internally anywhere without recognizing the existance
of that name as an internal part of the sys package.
If you explicitly export and import the right symbols manually, then
the code to do this automatically interns all the right things in the
right places, i.e., in order to say that you are importing certain
symbols you must introduce them to the reader properly qualified with
a package prefix. Hence you won't die having to unintern some symbol
which was read into the wrong place before the export/import happened.
I'm in favor of leaving the package system as it is, but I think the
manual (or a later spec) should contain alot of warnings about the
kinds of problems that use-package causes. The naive user almost
always thinks the easiest thing to do is have all his packages use
each-other. And if he does experience package problems, then the
naive view again is that making everything use everything solves
these problems. There is no "DWIM-with-all-the-symbols"; the control
of names in large systems requires a methodical, explicit approach.
...mike beckerle
Gold Hill Computers
∂19-Nov-86 2355 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET TYPE-OF
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 19 Nov 86 23:55:05 PST
Received: from utokyo-relay by csnet-relay.csnet id aa09456; 19 Nov 86 10:53 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA23688; Wed, 19 Nov 86 23:51:37+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA16856; Wed, 19 Nov 86 23:41:56+0900
Date: Wed, 19 Nov 86 23:41:56+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8611191441.AA16856@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: TYPE-OF
This mail is the reply to RAM's mail and RWK's mail.
(And I just read Fahlman's mail and Masinter' mail on posting this.
this mail is not directly related to my committee work for the standardization)
My trigger to think of TYPE-OF (and SUBTYPEP) is the definition of
the Common Lisp interpreter including CommonLoops.
I've been thinking of it since last November before PCL was there.
(And presented a paper on Dec. 1985 in Japan)
I named it Discriminating Eval (D-Eval).
D-Eval is an executable model of Common Lisp scheme.
D-Eval always keeps track of the type of a object.
With this D-Eval, Common Lisp can, I think, bridge the object oriented world and
lisp, and formal systems.
I feel several researchers are independently working in near here.
(If someone is interested in D-Eval I will send a version of it to anyone)
Here is a conversation with D-Eval:
D-Eval>(+ 1 2)
3
; FIXNUM
D-Eval>(cdr '(a))
()
; NULL
D-Eval>(ndefmeth foo ((x integer)) (+ x 1))
FOO
; SYMBOL
D-Eval>(foo 1)
2
; FIXNUM
...
Then, I will try to discuss.
>Date: Mon, 17 Nov 1986 18:03 EST
>From: Rob MacLachlan <RAM%C.CS.CMU.EDU@u-tokyo.junet>
>Received: from CSNet-Relay by utokyo-relay; 19 Nov 86 12:58:34-JST (Wed)
>
> ...
>It would also be wrong for NIL to be returned to indicate a random
>object, since NIL is a meaningful type, but not one that any object
>can posess. It would make more sense to return T or a new type such
>as RANDOM.
I understood. I confess that I did not make a deep consideration on random object prior to posting my mail.
I am wrong.
They should not goto NIL.
Thank you.
>I also have some doubts about the need to specify what Type-Of
>returns. Could you demonstrate some code that needs to use Type-Of
>and is adversely affected by different implementations? I suppose
>that we could rigorously specify some function that does what you
>want, but it shouldn't be Type-Of.
D-Eval concept needs TYPE-OF.
kinds of type inferencing system will also need TYPE-OF to determine the type.
>
> Rob
>
----------
>Date: Tue, 18 Nov 86 16:04 EST
>From: Robert W. Kerns <RWK%YUKON.SCRC.Symbolics.COM@u-tokyo.junet>
>In-Reply-To: <8611170906.AA16158@ccut.u-tokyo.junet>
>Received: from CSNet-Relay by utokyo-relay; 19 Nov 86 15:19:54-JST (Wed)
>
> ... Your question really relates to one of the core
>issues of this topic.
I think so if my image of SUBTYPEP is same as yours.
>
> ... And SUBTYPEP/TYPEP
>is what answers the question "is this object suitable."
>Given this model, there is no such thing as "too specific"
>an answer from TYPE-OF. On the contrary, the concern should
>be with "not specific enough".
>
>To address your specific points:
>
> Date: Mon, 17 Nov 86 18:06:12+0900
> From: Masayuki Ida <z30083%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
>
> ...
>
>For example, TYPE-OF of a number must return one of INTEGER, COMPLEX, FLOAT,
>RATIO, or one of their subtypes (if any), or some other subtype of NUMBER.
TYPE-OF of a number must return one of the FIXNUM, BIGNUM, RATIO, SHORT-FLOAT,
SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT, COMPLEX. If TYPE-OF can not return
one of the above, it must return the type which is closer to the above terminal type.
>
>However, it does not make sense to specify that TYPE-OF return one
>of FIXNUM or BIGNUM, rather than INTEGER; a system which implemented
>all numbers as "BIGNA" would be correct, if inefficient.
>
>And a system might reasonably have two kinds of BIGNUM's, NEGATIVE-BIGNUM and
>POSITIVE-BIGNUM. If you specify that TYPE-OF return just BIGNUM,
>you prevent any program from distinguishing between them, when it
>may be the program's advantage to make the distinction.
NEGATIVE-BIGNUM and POSITIVE-BIGNUM are not defined in Common Lisp,
though they are possible to exist.
>
>By over-specifying TYPE-OF, you can eliminate any implementation
>flexibility or extensibility.
TYPE-OF story and implementation flexibility are quite different.
I think the definition of TYPE-OF is needed to keep Common Lisp as well-defined.
It is the issue of formality.
What I said is TYPE-OF should return the name of the symbol which is defined in the language specification.
And,
the value (type) should be at the bottom of hierarchy chart whenever it is possible.
For example,
(type-of ()) should not be SYMBOL as in some CL implementations, but NULL.
>
> ...
>TYPE-OF returns POWER-OF-TWO-POSITIVE-BIGNUM, SUBTYPEP must return
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
this symbol is not in my dictionary.
Again, I think TYPE-OF should not return implementation dependent things.
>the values T T when asked if this is a subtype of BIGNUM, of INTEGER,
>and of NUMBER.
>
>SUBTYPEP is the only predicate provided for comparing types;
>it goes without saying that any code that uses something else
>like EQUAL will not be portable. Any type you get back from
>TYPE-OF you must interpret with SUBTYPEP.
>
> I had wrote a hierarchy chart based on 2.15.
> which is attached on the japanese edition of CLtL.
>
> Here is a brief sketch of it.
>The english version of CLtL would be clearer if it
>included something like this.
I think so. ( I already sent it to GLS)
>
> T>{pathname,stream,hash-table,readtable,package,random-state,
>
> 'nil' is for undefined object, say unreadable objects.
>No, not NIL. T would be a better choice here than NIL!
Thank you. As I answered to RAM's message, I am wrong.
>
> .... There is nothing wrong with having
>an UNDEFINED type, however. ...
Will you push to make UNDEFINED type ?
I think its interesting.
I want to add one more thing.
(type-of "string") must return SIMPLE-STRING. SIMPLE-STRING is a subtype of
STRING and SIMPLE-ARRAY simultaneously.
If this call returns STRING, SIMPLE-ARRAY related things can not handle
the things caused by (type-of "string").
Masayuki Ida
∂20-Nov-86 0703 RAM@C.CS.CMU.EDU type-of
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86 07:03:32 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 20 Nov 86 09:34:07-EST
Date: Wed, 19 Nov 1986 23:32 EST
Message-ID: <RAM.12256330165.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: type-of
In-reply-to: Msg of 18 Nov 1986 16:04-EST from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
I have also done some thinking about types in connection with my
project of writing a Common Lisp compiler that takes types seriously.
I tend to agree Sandra that your example demonstrates a problem in the
type system rather than a solution. Unless you have a better example,
what you are really demonstrating is the horrible lossage in the
definition of specialized array types.
I agree that it might be useful to be able to determine if an
object can be stored in an array, but I suggest that the problem be
solved by adding an Array-Can-Hold-P predicate. The problem is that
in principle, there is no reason why the "type" of object that can be
stored in a specialized array must be representable with a Common Lisp
type specifier. I guess that with your
ARRAY-POSITIVE-POWER-OF-TWO-BIGNUM example, you were suggesting that
it is always possible to do the back-mapping without losing
information, but I don't think that it is a good idea to require this.
Much of the confusion revolves around the lack of distinction
between types and objects. When the implementation decides to
create an instance of a type, it chooses a representation. This
mapping between types and representations is neither injective nor
surjective. The implementation may decide to discard information, as
in (ARRAY SYMBOL) ==> (ARRAY T). It may also decide to add
information, as in INTEGER ==> FIXNUM.
Many functions in the language use the to-implementation mapping;
I believe that only Type-Of and Array-Element-Type attempt to perform
the from-implementation mapping. If these functions are ignored, then
implementation's freedom to choose representations is totally
invisible, and is restricted only by the requirements that certain
types "are disjoint".
I think that any attempt to use Type-Of or Array-Element-Type in
code is highly suspect. The only such use that I know of is to find the
type of an object which is known to be a structure; this is presumably
what Class-Of does. Note that in this case, Type-Of is actually doing
something totally different from what it normally does: it is making
no attempt to return the "most specific type"; instead it is making a
well-defined from-implementation mapping based on an explicitly
defined type hierarchy. If we treated objects other than structures
the same way, then we could make a similar back-mapping for them.
This capability seems to be what Ida seems to be interested in, but it
isn't what Type-Of does.
Rob
∂20-Nov-86 0747 cfry%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU fboundp question
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86 07:47:47 PST
Received: from JONES.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 20 Nov 86 06:12-EST
Date: Thu, 20 Nov 86 06:12 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: fboundp question
To: common-lisp@SU-AI.ARPA
Message-ID: <861120061242.7.CFRY@JONES.AI.MIT.EDU>
(fboundp 'cond) => ?
(fboundp 'go) => ?
I am not happy with the spec on symbol-function.
∂20-Nov-86 1020 DLW@ALDERAAN.SCRC.Symbolics.COM side comment
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 Nov 86 10:20:40 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22688; Thu 20-Nov-86 13:19:12 EST
Date: Thu, 20 Nov 86 13:20 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: side comment
To: common-lisp@SU-AI.ARPA
Message-ID: <861120132014.2.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Wed, 19 Nov 1986 23:32 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Unless you have a better example,
what you are really demonstrating is the horrible lossage in the
definition of specialized array types.
Side comment: This is what happens when experienced, well-intentioned
Lisp experts decide to put an untested new idea into a language
standard. In many, perhaps most, cases where we put in new ideas that
had not been tested in "production" circumstances, we got nasty
surprises much later. This is a fine thing to happen in a growing Lisp
implementation, but not a fine thing to happen in a stable Lisp
standard.
∂20-Nov-86 1032 spe@cad.cs.cmu.edu EVAL
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86 10:32:21 PST
Date: 20 Nov 1986 13:28-EST
From: Sean.Engelson@cad.cs.cmu.edu
To: common-lisp@SU-AI.ARPA
Subject: EVAL
Message-Id: <532895293/spe@cad.cs.cmu.edu>
Why is it that EVAL returns the value in the current DYNAMIC
environment, rather than the lexical environment? Or perhaps the most
recent binding (lexical unless a variable is special)? Or if this is
necessary for some reason, why isn't there another function, say,
LEXICAL-EVAL that does this? It seems rather strange to have a mainly
lexically scoped language with no facility for lexical evaluation.
∂20-Nov-86 1150 DLW@VALLECITO.SCRC.Symbolics.COM TYPE-OF
Received: from SCRC-VALLECITO.ARPA by SAIL.STANFORD.EDU with TCP; 20 Nov 86 11:50:45 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71990; Thu 20-Nov-86 14:49:44 EST
Date: Thu, 20 Nov 86 13:34 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: TYPE-OF
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
In-Reply-To: <8611191441.AA16856@ccut.u-tokyo.junet>
Message-ID: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
OK, I think it's clear that you don't really want TYPE-OF to return "the
most specific type". Rather, you want it to be the case that TYPE-OF is
well-defined for all objects in Common Lisp, and that the definition,
which will be written out clearly somewhere, will tend to specify that
more-specific rather than less-specific types be returned. If some
implementation has its own even-more-specific type, TYPE-OF will not
return it.
Even so, I'm not sure I understand why you need TYPE-OF. As far as I
can tell, almost the only useful thing to do with a type is to see
whether some object is of that type, and that's what TYPEP is for.
In your D-Eval example, evaluating (foo 1) returned 2 and printed out ";
FIXNUM". If you had said (foo 0), it would have returned 1, but would
it have printed out "; BIT"? Apparently not, because that's not in your
list of number types. On the other hand, why doesn't 2 print out ";
INTEGER"? That is, why does your list exclude BIT but include FIXNUM
and BIGNUM? Whether an integer is a FIXNUM or not depends on the
implementation, and usually it's better to hide it than draw attention
to it. Same question for the different floating point formats. In
order to make TYPE-OF fully-defined, some kinds of decisions have to be
made, and some of them seem rather arbitrary (in the sense that it's not
really clear which decision is best).
∂20-Nov-86 1217 gls@think.com TYPE-OF
Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86 12:17:09 PST
Received: from hilarion by Godot.Think.COM via CHAOS; Thu, 20 Nov 86 15:23:53 EST
Date: Thu, 20 Nov 86 15:16 EST
From: Guy Steele <gls@think.com>
Subject: TYPE-OF
To: DLW@alderaan.scrc.symbolics.com,
a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@relay.cs.net,
common-lisp@su-ai.arpa, ida%u-tokyo.junet@relay.cs.net
Cc: gls@aquinas.think.com
In-Reply-To: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-Id: <861120151614.4.GLS@HILARION.THINK.COM>
One might want (TYPE-OF 2) => (INTEGER 2 2), or perhaps just (INTEGER 2)
and define (INTEGER x) <=> (integer x x). But this does not seem to
generalize nicely to other data types.
If the goal is that TYPE-OF should return the most specific possible
type, then clearly when applied to object x it should return (MEMBER x),
as that is the most specific type that contains x. But this is not
very useful, and therefore this goal is not what we really want.
--Guy
∂20-Nov-86 1250 RPG TYPE-OF
To: common-lisp@SAIL.STANFORD.EDU
Given the recent re-discovery that TYPE-OF cannot be defined to have the
same precise behavior in all Common Lisps, it seems we should rename
`types' to be `sorts' and therefore rename `TYPE-OF' to be `SORT-OF.'
-rpg-
∂20-Nov-86 1325 FAHLMAN@C.CS.CMU.EDU EVAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86 13:20:19 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 20 Nov 86 16:19:24-EST
Date: Thu, 20 Nov 1986 16:19 EST
Message-ID: <FAHLMAN.12256513463.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Sean.Engelson@CAD.CS.CMU.EDU
Cc: common-lisp@SU-AI.ARPA
Subject: EVAL
In-reply-to: Msg of 20 Nov 1986 13:28-EST from Sean.Engelson at cad.cs.cmu.edu
Why is it that EVAL returns the value in the current DYNAMIC
environment, rather than the lexical environment? Or perhaps the most
recent binding (lexical unless a variable is special)? Or if this is
necessary for some reason, why isn't there another function, say,
LEXICAL-EVAL that does this? It seems rather strange to have a mainly
lexically scoped language with no facility for lexical evaluation.
EVAL cannot easily be defined to work in the lexical environment in
which it appears because that lexical environment is not around at
runtime, when the argument to EVAL arrives and the evaluation occurs.
In any event, it would eliminate many of the benefits of lexical scoping
to provide a loophole through which arbitrary forms might be smuggled
into a lexical environment at runtime. For example, certain
optimization are now possible because the compiler can examine all
possible references to a lexically-bound variable by scanning the
lexical block in which it is bound; thsi would go away in the presence
of your LEXICAL-EVAL.
So the language specifies that EVAL operates within the current dynamic
environment and the null lexical environment, and it does not provide a
way to pass a non-null lexical environment to EVAL.
For debugging, it is useful to be able to access lexical variables by
name, but this falls outside of the language proper. It does not need
to be portable and it does not need to work in code that has been
altered beyond recognition by the compiler.
I must have answered this question a hundred times, both on this mailing
list and elsewhere. We'd better put a "rationale" statement intot he
next version of the manual, since people seem to find this more
confusing than anything else (except maybe packages and case conversion).
-- Scott
∂20-Nov-86 1433 DLW@ELEPHANT-BUTTE.SCRC.Symbolics.COM TYPE-OF
Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86 14:33:25 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 111079; Thu 20-Nov-86 14:48:32 EST
Date: Thu, 20 Nov 86 13:34 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: TYPE-OF
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET,
common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
In-Reply-To: <8611191441.AA16856@ccut.u-tokyo.junet>
Message-ID: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
OK, I think it's clear that you don't really want TYPE-OF to return "the
most specific type". Rather, you want it to be the case that TYPE-OF is
well-defined for all objects in Common Lisp, and that the definition,
which will be written out clearly somewhere, will tend to specify that
more-specific rather than less-specific types be returned. If some
implementation has its own even-more-specific type, TYPE-OF will not
return it.
Even so, I'm not sure I understand why you need TYPE-OF. As far as I
can tell, almost the only useful thing to do with a type is to see
whether some object is of that type, and that's what TYPEP is for.
In your D-Eval example, evaluating (foo 1) returned 2 and printed out ";
FIXNUM". If you had said (foo 0), it would have returned 1, but would
it have printed out "; BIT"? Apparently not, because that's not in your
list of number types. On the other hand, why doesn't 2 print out ";
INTEGER"? That is, why does your list exclude BIT but include FIXNUM
and BIGNUM? Whether an integer is a FIXNUM or not depends on the
implementation, and usually it's better to hide it than draw attention
to it. Same question for the different floating point formats. In
order to make TYPE-OF fully-defined, some kinds of decisions have to be
made, and some of them seem rather arbitrary (in the sense that it's not
really clear which decision is best).
∂20-Nov-86 1532 Pavel.pa@Xerox.COM Re: fboundp question
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86 15:27:20 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 86 14:24:35 PST
Date: 20 Nov 86 14:24 PST
From: Pavel.pa@Xerox.COM
Subject: Re: fboundp question
In-reply-to: Christopher Fry <cfry@OZ.AI.MIT.EDU>'s message of Thu, 20
Nov 86 06:12 EST
To: cfry@OZ.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <861120-142435-4722@Xerox>
Page 71: ``We say that a predicate `is true' when it returns a non-NIL
value''
Page 90-91: ``FBOUNDP is true if the symbol has a global function
definition. Note that FBOUNDP is true when the symbol names a special
form or macro.''
Page 116: ``COND {(test {form}*)}* [Macro]''
Page 133: ``GO tag [Special Form]''
Therefore,
(fboundp 'cond) => a non-NIL value
(fboundp 'go) => a non-NIL value
Nothing more is guaranteed by the language definition. Xerox and Lucid
Lisps return T in both cases.
Pavel
∂21-Nov-86 0242 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET question: EVAL
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 21 Nov 86 02:42:07 PST
Received: from utokyo-relay by csnet-relay.csnet id ac01740; 21 Nov 86 4:56 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA11733; Fri, 21 Nov 86 18:10:26+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA12885; Fri, 21 Nov 86 17:49:44+0900
Date: Fri, 21 Nov 86 17:49:44+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8611210849.AA12885@ccut.u-tokyo.junet>
To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: question: EVAL
In the list of GLS, there is an EVAL extension to have an optional argument
for 'environment'.
will it be defined in the comming specification ?
Is this only one argument ?
Does the value of this optional 'environmental' argument have a defined
syntax/semantics ?
ida
∂21-Nov-86 0613 RAM@C.CS.CMU.EDU question: EVAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86 06:13:05 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 21 Nov 86 09:12:26-EST
Date: Fri, 21 Nov 1986 09:12 EST
Message-ID: <RAM.12256697887.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: question: EVAL
In-reply-to: Msg of Fri 21 Nov 86 17:49:44+0900 from Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
You can use Evalhook to evaluate a form in an environment,
supposing that you can get your hands on one. Currently the only
way to get your hands on a guaranteed evaluation environment is to use
*evalhook* or *applyhook*. With such an environment, the semantics
are well defined. Some implementations that don't have an evaluator
don't support *evalhook* though...
Rob
∂21-Nov-86 0637 RAM@C.CS.CMU.EDU TYPE-OF
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86 06:37:07 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 21 Nov 86 09:36:58-EST
Date: Fri, 21 Nov 1986 09:36 EST
Message-ID: <RAM.12256702349.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Subject: TYPE-OF
In-reply-to: Msg of Wed 19 Nov 86 23:41:56+0900 from Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
Date: Wed, 19 Nov 86 23:41:56+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
To: common-lisp at SU-AI.ARPA, ida%u-tokyo.junet at RELAY.CS.NET
Re: TYPE-OF
D-Eval concept needs TYPE-OF. kinds of type inferencing system
will also need TYPE-OF to determine the type.
Here is a conversation with D-Eval:
D-Eval>(+ 1 2)
3
; FIXNUM
Well, if all D-Eval uses Type-Of for is to print out the type, then it
doesn't really matter what it returns. I had in mind a fragment of
code that needed to use Type-Of. I don't know exactly what you mean
by a "type inferencer", but for the kinds of type inferences that I
could conceive of a Lisp compiler wanting to do, you definitely want
the *most specific* type, and certainly don't want to return random
things such as FIXNUM which represent implementation details rather
than language semantics.
Suppose that I was examining the expression:
(+ (aref a 3) 7)
Now, if A is known (due to declaration) to be
(array (unsigned-byte 8)), then I could combine the fact that 7 is
(integer 7 7) with that information to determine that the result of the
addition is (integer 262 7), which is probably a useful thing to know.
If all that I know is that 7 is FIXNUM, then all bets are off.
I didn't mention this on the mailing list as a valid use of Type-Of,
since:
1] The compiler *is* the implementation, so it doesn't matter if it
is implementiaton dependent.
2] The version of Type-Of that I am using in the compiler is
optimized to return what the compiler considers most interesting,
rather than what the user might consider most informative. For
example, given a symbol, it returns (member <symbol>).
Rob
∂21-Nov-86 0808 Moon@STONY-BROOK.SCRC.Symbolics.COM Packages
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 08:08:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5975; Thu 20-Nov-86 20:24:05 EST
Date: Thu, 20 Nov 86 20:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Packages
To: wile@ISI-VAXA.ARPA
cc: COMMON-LISP@SU-AI.ARPA
In-Reply-To: <8611182057.AA08142@vaxa.isi.edu>
Message-ID: <861120202347.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 18 Nov 1986 1257-PST (Tuesday)
From: wile@ISI-VAXA
I believe inclusion of packages is the worst mistake in Common LISP's
design. There isn't a day goes by (when I actually get to program or
debug) when I don't have package problems....
I am looking for conventions that make packages easier to live with.
I am surprised that you have not noticed that Common Lisp does NOT require the
programmer to use packages. The only packages Common Lisp requires you to
know about are USER, LISP, and KEYWORD. You can ignore the distinction
between USER and LISP, and pretend that KEYWORD symbols are just symbols with
colons in their names, and get along just fine. Of course you don't get any
of the benefits of packages this way, but you don't get any of the problems,
either. Another way to look at it is that Common Lisp contains the
Maclisp/Interlisp one-symbol-namespace dialect as a subset.
I do not mean by this comment to stifle anyone's research into better
modularity facilities for Lisp than packages. I am confident that something
better will eventually be invented, developed, and tempered in the fire of
real-life use. Several promising ideas have already come forth (starting at
least 22 years ago, actually). If any of those ideas are so well-developed
and problem-free that they are ready for universal adoption, I haven't heard
about it yet, but I'm sure it's bound to happen eventually.
∂21-Nov-86 0944 wile@vaxa.isi.edu Package solution "motivation"
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86 09:44:50 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA11398; Fri, 21 Nov 86 09:45:10 pst
Message-Id: <8611211745.AA11398@vaxa.isi.edu>
Date: 21 Nov 1986 0945-PST (Friday)
To: COMMON-LISP@SU-AI.ARPA
From: wile@ISI-VAXA
Subject: Package solution "motivation"
I was afraid of that. Everyone jumped on the complaint and ignored the
proposal. I'll complain more succinctly in a separate message.
The problem I am trying to solve, as a producer of software that
manipulates program specifications and implementations, is to allow my
users to be as unconcerned with packages as possible.
I have written a system, called Popart, which takes BNF grammars extended
with regular expressions and operator precedence, a produces a parser,
lexical analyzer, pretty printer, pattern matcher, (old style) structure
editor, and transformation system for the language written in that grammar.
Of course, I have tried to integrate the facility consistent with Common
LISP conventions, rather than just deeming packages "red herrings" to be
ignored. Generally, our use of Popart will be to allow users to specify
the functionality of their application in a language we call Gist,
transform that specification into a language we call Will, which will be
automatically compiled into Common LISP.
Yesterday's comment that "the user must have a firm model of the package
structure" is right on. Consider the packages involved in the scenario
above:
Grammar parse tree structures
Grammar constants
Grammar grammar parse tree structures
Grammar grammar constants
Transformation definition language parse tree
" " " " " " constants
Transformation definitions themselves (their names, like
divide-and-conquer, duplicate-arm-motion-removal, ...)
User Gist symbols (Gist application package, e.g. relation names,
agent names)
User Will symbols (e.g. demon names, type definitions)
LISP and below
Obviously, creating the right defaulting mechanism is very important here.
The first major decision was to put all grammar constants (begin, end, +,
etc.) in the keyword package for all grammars. I would prefer to put them
into the uninterned symbol (non)package, but I don't know how to read into
that package. The reason I would prefer to do this is partially an
efficiency issue. If I could read symbols that way, I could decide to put
the (few) symbols whose packages matter (names of functions, defined
entities in the users' languages) in that package. The only option I seem
to have is to read everything into the user's package and change them into
grammar constants when I see that that name has been used in the grammar.
Perhaps I could read everything into the keyword package, but I had visions
of creating lots of garbage keyword symbols. I don't know... Reading the
symbol uninterned and then deciding where to intern it seems conceptually
the right hook. Thus, the proposal to allow read an optional functional
parameter to decide where to put the symbol.
[Incidentally, the other defaults:
Grammar grammar parse tree structures are in the parser's package.
Transformation definition language parse trees are in the transformation
system's package.
Transformation definitions themselves are in the grammar's package for
which language they are transformations.
User Gist and Will symbols are in packages defined (used) by the user
(just as function definitions, variable definitions, etc., are in
Lisp)
]
Sorry for the vitriolic attack. (I'd tried to make it many times before,
with no proposed solution, so I'd resisted. I thought I was being positive
with my proposal.) Perhaps now you understand my frustration...
Dave Wile
∂21-Nov-86 1152 RWK@STONY-BROOK.SCRC.Symbolics.COM type-of
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 11:51:57 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6714; Fri 21-Nov-86 14:44:48 EST
Date: Fri, 21 Nov 86 14:46 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: type-of
To: Sandra J Loosemore <sandra%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8611191611.AA14790@utah-orion.ARPA>
Supersedes: <861121144528.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <861121144625.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Wed, 19 Nov 86 09:11:01 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
From: RWK@YUKON.SCRC.Symbolics.COM (Robert W. Kerns)
Date: 18 Nov 86 21:04:00 GMT
Here is an example of completely-portable code which depends on
TYPE-OF returning the MOST specific type.
(defun store-in-array-if-fits (object array &rest indicies)
(let ((object-type (type-of object))
(array-type (array-element-type array)))
(if (subtypep object-type array-type)
;; If the object fits, store it
(setf (apply #'aref array indicies) object)
;; Doesn't fit, so store 0 instead.
(setf (apply #'aref array indicies) 0))))
Sorry, I can't buy this motivation. All this example illustrates is that
there is a good reason for having the TYPEP function around.
(defun typep (object type)
(subtypep (type-of object) type))
Yes, my example is a bit oversimplified; I was more interested in
demonstrating portability than necessity. And the "important half"
of TYPEP is SUBTYPEP, not TYPE-OF. But TYPEP doesn't let you
make the decision about the type separately from the object in
question.
As it happens, in PCLS, TYPE-OF does go through a considerable amount of
work to find the most specific type that it can. So, (TYPE-OF 0) returns
BIT, which is correct but largely useless. My "gut feeling" is that what
the user probably wants is either FIXNUM or INTEGER -- something which
indicates how the object is represented internally, or (in other words)
one of the set of types which CLtL says are disjoint.
If the user is writing his code properly, he is using
type-comparison (i.e. SUBTYPEP), so he doesn't really
care. But your "gut feeling" is right, he probably
doesn't care about anything more specific than
FIXNUM.
That's why I think it would be advantagious to more
precisely specify TYPE-OF. Right now the spec could
be read as requiring (TYPE-OF 0) => BIT. If we specify
a "least specific" type (FIXNUM in this case), than
any implementation which returns something *at least*
as specific as FIXNUM is fine. If an implementation
has reason for being more specific, however, it should
be free to do so.
I'll have to agree that TYPE-OF as defined now is pretty bogus. The only
place I've ever had reason to use TYPE-OF in real code was to get a type
to pass to COERCE or CONCATENATE, etc., when I wanted to ensure that two
objects were of the same type; for example, both lists or whatever. But
this is full of holes, too. For example,
(coerce '#(a b c) (type-of (list)))
may fail, depending on whether your favorite implementation thinks NIL is
of type NULL, LIST, or SYMBOL. I ended up writing a specialized function
to do what I wanted, without relying on TYPE-OF.
This is just a matter of TYPE-OF not being specific enough
together with COERCE not being general enough. If TYPE-OF
is properly specific (i.e. NULL), and COERCE finds the
"least supertype" of the argument type that it supports
(for example, if you wrote it with TYPECASE or SUBTYPEP,
rather than EQL), then there's no problem.
Our entire user-interface in Release 7 is based on just
type sort of question. It is fundamental to any theory
of TYPEP, as well. I freely admit that it isn't often
called, but that's not a reason to eliminate it, or to
leave it sloppily specified.
In short, I am not convinced that TYPE-OF would be particularly useful even
if its definition were firmed up more. If nobody has any good use for this
function, arguing over how it should behave is rather pointless.
I think your own example contradicts this position.
∂21-Nov-86 1231 RWK@STONY-BROOK.SCRC.Symbolics.COM TYPE-OF
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 12:31:44 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6790; Fri 21-Nov-86 15:29:36 EST
Date: Fri, 21 Nov 86 15:30 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: TYPE-OF
To: Guy Steele <gls@think.com>
cc: DLW@ALDERAAN.SCRC.Symbolics.COM,
a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@relay.cs.net,
common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@relay.cs.net
In-Reply-To: <861120151614.4.GLS@HILARION.THINK.COM>
Message-ID: <861121153042.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 20 Nov 86 15:16 EST
From: Guy Steele <gls@think.com>
One might want (TYPE-OF 2) => (INTEGER 2 2), or perhaps just (INTEGER 2)
and define (INTEGER x) <=> (integer x x). But this does not seem to
generalize nicely to other data types.
If the goal is that TYPE-OF should return the most specific possible
type, then clearly when applied to object x it should return (MEMBER x),
as that is the most specific type that contains x. But this is not
very useful, and therefore this goal is not what we really want.
--Guy
Right. That's why I proposed specifying a "least specific"
type, saying that "it must be at least this specific". Combine
this with the requirement that whatever is actually returned
must be understood by SUBTYPEP (i.e. SUBTYPEP of that type
and the "least specific" type specified must return T T).
∂21-Nov-86 1300 RWK@STONY-BROOK.SCRC.Symbolics.COM TYPE-OF
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 12:59:48 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6852; Fri 21-Nov-86 15:57:48 EST
Date: Fri, 21 Nov 86 15:58 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: TYPE-OF
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
cc: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>,
common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
In-Reply-To: <RAM.12256702349.BABYL@C.CS.CMU.EDU>
Message-ID: <861121155855.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Fri, 21 Nov 1986 09:36 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Date: Wed, 19 Nov 86 23:41:56+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
To: common-lisp at SU-AI.ARPA, ida%u-tokyo.junet at RELAY.CS.NET
Re: TYPE-OF
D-Eval concept needs TYPE-OF. kinds of type inferencing system
will also need TYPE-OF to determine the type.
Here is a conversation with D-Eval:
D-Eval>(+ 1 2)
3
; FIXNUM
Well, if all D-Eval uses Type-Of for is to print out the type, then it
doesn't really matter what it returns. I had in mind a fragment of
code that needed to use Type-Of. I don't know exactly what you mean
by a "type inferencer", but for the kinds of type inferences that I
could conceive of a Lisp compiler wanting to do, you definitely want
the *most specific* type, and certainly don't want to return random
things such as FIXNUM which represent implementation details rather
than language semantics.
Eh? You're contradicting yourself.
Compilers deal directly with implementation, and that's
why you want something more specific, such as FIXNUM,
rather than something at the level of language semantics,
such as INTEGER. I think you're trying to argue that you
want something more specific still, but that's not TYPE-OF's
job.
Now, if A is known (due to declaration) to be
(array (unsigned-byte 8)), then I could combine the fact that 7 is
(integer 7 7) with that information to determine that the result of the
addition is (integer 262 7), which is probably a useful thing to know.
If all that I know is that 7 is FIXNUM, then all bets are off.
If all you have is TYPE-OF and SUBTYPEP, yes, that is true.
If you don't want to throw away information, keep the
original object.
In a recent message, I oversimplified TYPEP, because I'm
trying to stay out of certain issues better handled in
a paper, where hopefully I can be more careful and
verbose. So I lied a little. Let's consider that
lie for a moment. (My apologies for presenting all of
this in such a fragmentary way).
In that other message, I defined TYPEP as
(defun typep (object type)
(subtypep (type-of object) type))
This mostly works. However, this depends on TYPE-OF
returning the most-specific type, so for any appropriate
type for an object, TYPE-OF will return something at
least as specific, and which SUBTYPEP can decide on.
Let me assert at this point, without proof, that there
is no such single type.
The problem is that TYPE-OF is inherently an information-losing
operation. The pair TYPE-OF/SUBTYPEP is actually a special
case of a more general matching process that I really don't want
to go into right now. The key point, however, is that TYPEP
actually does some things that SUBTYPEP can't, because it actually
has the object. The same is true of your "type merger" for addition,
which should look at the actual object when it has one, and not
call TYPE-OF.
I didn't mention this on the mailing list as a valid use of Type-Of,
since:
1] The compiler *is* the implementation, so it doesn't matter if it
is implementiaton dependent.
2] The version of Type-Of that I am using in the compiler is
optimized to return what the compiler considers most interesting,
rather than what the user might consider most informative. For
example, given a symbol, it returns (member <symbol>).
This is an interesting approach. It reduces TYPE-OF/SUBTYPEP to TYPEP!
∂21-Nov-86 1519 sandra%utah-orion@utah-cs.arpa Re: type-of
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 15:19:00 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA20321; Fri, 21 Nov 86 16:20:00 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA07808; Fri, 21 Nov 86 16:19:56 MST
Date: Fri, 21 Nov 86 16:19:56 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8611212319.AA07808@utah-orion.ARPA>
Subject: Re: type-of
To: Robert W. Kerns <RWK@scrc-yukon.arpa>
Cc: common-lisp@su-ai.arpa
In-Reply-To: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>, Fri, 21 Nov 86 14:46 EST
Two comments on your comments.
First of all, neither TYPE-OF or SUBTYPEP is necessary for implementing
TYPEP. In fact, doing it that way is probably the most inefficient
implementation possible. In PCLS, for example, all of the built-in types
like INTEGER or SIMPLE-STRING have predicates associated with them that
can be found by a quick lookup procedure, and there is special logic for
handling the more complicated type specifiers like (ARRAY ...).
I agree that TYPE-OF should not be thrown out just because nobody uses
it much, *provided* that the function is there because it implements some
functionality users could not easily implement themselves. For the uses
of TYPE-OF that people have mentioned so far, this is not the case. Here
is a portable, 3-line function that will check an object against whatever
set of type specifiers I think are appropriate in this situation:
(defun my-type-of (object possible-type-spec-list)
(dolist (type possible-type-spec-list t)
(if (typep object type) (return type))))
The only case where this would fail would be if I do not know in advance
what type specifiers I want to see returned. Gee whiz! Isn't that what
TYPE-OF is supposed to do now? :-)
-Sandra
-------
∂21-Nov-86 1657 RAM@C.CS.CMU.EDU TYPE-OF
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86 16:57:10 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 21 Nov 86 19:57:05-EST
Date: Fri, 21 Nov 1986 19:57 EST
Message-ID: <RAM.12256815241.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: TYPE-OF
In-reply-to: Msg of 21 Nov 1986 15:58-EST from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
Date: Friday, 21 November 1986 15:58-EST
From: Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
To: Rob MacLachlan <RAM>
Date: Fri, 21 Nov 1986 09:36 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
... I don't know exactly what you mean
by a "type inferencer", but for the kinds of type inferences that I
could conceive of a Lisp compiler wanting to do, you definitely want
the *most specific* type, and certainly don't want to return random
things such as FIXNUM which represent implementation details rather
than language semantics.
Eh? You're contradicting yourself.
Nope, (INTEGER 3 3) is more specific than FIXNUM, which is after all
just (INTEGER most-negative-fixnum most-positive-fixnum).
Compilers deal directly with implementation, and that's
why you want something more specific, such as FIXNUM,
rather than something at the level of language semantics,
such as INTEGER. I think you're trying to argue that you
want something more specific still, but that's not TYPE-OF's
job.
What we are trying to determine is what TYPE-OF's jobs is. I
introduced my compiler example, not necessarily because I thought that
TYPE-OF should do what my CTYPE-OF does, but because I wanted to
challenge Ida's contention that TYPE-OF was useful for type inference.
I.e. I am still trying to home in on a valid use for TYPE-OF. The way
that type inference is done by my compiler is irrelevant; I simply
wanted to show that Ida's TYPE-OF is useless in my type inferencer.
In a recent message, I oversimplified TYPEP, [...]
This mostly works. However, this depends on TYPE-OF
returning the most-specific type, so for any appropriate
type for an object, TYPE-OF will return something at
least as specific, and which SUBTYPEP can decide on.
Let me assert at this point, without proof, that there
is no such single type.
The problem is that TYPE-OF is inherently an information-losing
operation. [...]
I think we are agreeing violently. My main disagreement with you is
over whether there is a way to make TYPE-OF as strongly defined as you
want without pointlessly constraining the implementation, and if so
whether it is worth the bother (and core). People have written a
number of programs without a well-defined TYPE-OF/SUBTYPEP. It is not
clear we should foist additional overhead on Common Lisp just to make
the semantics of a nearly useless operation esthetically appealing.
Rob
∂22-Nov-86 1433 @REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU EVAL
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 14:33:00 PST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 12420; Sat 22-Nov-86 17:32:40 EST
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: EVAL
To: Fahlman@C.CS.CMU.EDU
cc: Sean.Engelson@CAD.CS.CMU.EDU, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12256513463.BABYL@C.CS.CMU.EDU>
Message-ID: <861122173233.4.ALAN@PIGPEN.AI.MIT.EDU>
Date: Thu, 20 Nov 1986 16:19 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
EVAL cannot easily be defined to work in the lexical environment in
which it appears because that lexical environment is not around at
runtime, when the argument to EVAL arrives and the evaluation occurs.
In any event, it would eliminate many of the benefits of lexical
scoping to provide a loophole through which arbitrary forms might be
smuggled into a lexical environment at runtime. For example, certain
optimization are now possible because the compiler can examine all
possible references to a lexically-bound variable by scanning the
lexical block in which it is bound; thsi would go away in the presence
of your LEXICAL-EVAL....
Right. This demonstrates that LEXICAL-EVAL would have to be a new special
form, rather than simply a function.
∂22-Nov-86 1701 Pavel.pa@Xerox.COM Re: EVAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Nov 86 17:00:55 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 86 17:00:37 PST
Date: 22 Nov 86 17:00 PST
From: Pavel.pa@Xerox.COM
Subject: Re: EVAL
In-reply-to: Alan Bawden <Alan@AI.AI.MIT.EDU>'s message of Sat, 22 Nov
86 17:32 EST
To: Alan@AI.AI.MIT.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <861122-170037-2387@Xerox>
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Right. This demonstrates that LEXICAL-EVAL would have to be a
new special form, rather than simply a function.
Even if it were a special form, what code could the compiler generate
for it? Would the presence of such a special form require turning off
all optimizations having to do with the lexical environment and cause
the compiler to create some sort of run-time environment structure
containing names and such? Yecch.
Pavel
∂22-Nov-86 1743 ricks%shambhala.Berkeley.EDU@BERKELEY.EDU Macrolet and setf
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 17:42:53 PST
Received: by ucbvax.Berkeley.EDU (5.53/1.18)
id AA16854; Sat, 22 Nov 86 17:42:37 PST
Received: by shambhala.berkeley.edu (4.12/5.6)
id AA02560; Sat, 22 Nov 86 15:04:06 pst
From: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L Spickelmier)
Message-Id: <8611222304.AA02560@shambhala.berkeley.edu>
Date: 22 Nov 1986 1504-PST (Saturday)
To: COMMON-LISP@su-ai.arpa
Subject: Macrolet and setf
Are macros defined with macrolet allowed as place forms in setf?
I have tried the following in VAXLISP and EXCL with both reporting
that 'mmm' can not be used as a place form (interpreted and compiled).
(defun abc (n)
(macrolet ((mmm (z) `(gethash ,z *bob*)))
(setf (mmm n) 5)))
Rick Spickelmier
UC Berkeley
∂22-Nov-86 1820 @REAGAN.AI.MIT.EDU:Alan@AI.AI.MIT.EDU Re: EVAL
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 18:20:29 PST
Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 12445; Sat 22-Nov-86 21:20:12 EST
Date: Sat, 22 Nov 86 21:20 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Subject: Re: EVAL
To: Pavel.pa@Xerox.COM
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <861122-170037-2387@Xerox>
Message-ID: <861122212008.0.ALAN@PIGPEN.AI.MIT.EDU>
Date: 22 Nov 86 17:00 PST
From: Pavel.pa@Xerox.COM
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Right. This demonstrates that LEXICAL-EVAL would have to be a new
special form, rather than simply a function.
Even if it were a special form, what code could the compiler generate
for it? Would the presence of such a special form require turning off
all optimizations having to do with the lexical environment and cause
the compiler to create some sort of run-time environment structure
containing names and such? Yecch.
That would seem to be what you have to do. The variables that are
lexically apparent at the site of the LEXICAL-EVAL would have to be handled
somewhat more carefully than ordinary lexical variables. Presumably by
bundling them up into some kind of explicit environment structure.
In Common Lisp you would also have to include the current function
definitions established by FLET, the current BLOCK names and TAGBODY tags,
and the current macro definitions established by MACROLET.
Please note that I have yet to express an opinion about this.
∂22-Nov-86 1922 Pavel.pa@Xerox.COM Re: Macrolet and setf
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Nov 86 19:22:16 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 86 19:21:22 PST
Date: 22 Nov 86 19:21 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Macrolet and setf
In-reply-to: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L
Spickelmier)'s message of 22 Nov 86 15:04 PST (Saturday)
To: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU
cc: COMMON-LISP@su-ai.arpa
Message-ID: <861122-192122-2541@Xerox>
Date: 22 Nov 86 15:04 PST (Saturday)
From: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L
Spickelmier)
Are macros defined with macrolet allowed as place forms in setf?
I have tried the following in VAXLISP and EXCL with both
reporting that 'mmm' can not be used as a place form (interpreted
and
compiled).
(defun abc (n)
(macrolet ((mmm (z) `(gethash ,z *bob*)))
(setf (mmm n) 5)))
I believe that VAXLISP and EXCL are both in error. Xerox, Lucid, and
Symbolics all do this correctly.
Pavel
∂22-Nov-86 1932 franz!ficl!jkf@ucbarpa.Berkeley.EDU Re: Macrolet and setf
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 19:32:14 PST
Received: by ucbarpa.Berkeley.EDU (5.57/1.18)
id AA14358; Sat, 22 Nov 86 19:32:14 PST
Received: from ficl by franz (5.5/3.14)
id AA22968; Sat, 22 Nov 86 18:51:35 PST
Received: by ficl (5.5/3.14)
id AA08389; Sat, 22 Nov 86 18:52:05 PST
From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <ficl!jkf>
Message-Id: <8611230252.AA08389@ficl>
To: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L Spickelmier)
Cc: COMMON-LISP@su-ai.arpa
Subject: Re: Macrolet and setf
In-Reply-To: Your message of Sat, 22 Nov 86 15:04:00 PST.
<8611222304.AA02560@shambhala.berkeley.edu>
Date: Sat, 22 Nov 86 18:52:02 PST
>> (defun abc (n)
>> (macrolet ((mmm (z) `(gethash ,z *bob*)))
>> (setf (mmm n) 5)))
I believe that the preceeding should be permitted, but it requires that
get-setf-method be permitted to take a second, environment, argument.
Such a change may have already been proposed.
-john foderaro
franz inc.
∂22-Nov-86 2052 FAHLMAN@C.CS.CMU.EDU Macrolet and setf
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 20:51:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 22 Nov 86 23:51:50-EST
Date: Sat, 22 Nov 1986 23:51 EST
Message-ID: <FAHLMAN.12257120126.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: franz!ficl!jkf@λucbarpa.Berkeley.EDU (John Foderaro)λ
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Macrolet and setf
In-reply-to: Msg of 22 Nov 1986 21:52-EST from franz!ficl!jkf at ucbarpa.Berkeley.EDU (John Foderaro)
>> (defun abc (n)
>> (macrolet ((mmm (z) `(gethash ,z *bob*)))
>> (setf (mmm n) 5)))
I believe that the preceeding should be permitted, but it requires that
get-setf-method be permitted to take a second, environment, argument.
Such a change may have already been proposed.
You're right, that's what it takes, and this change has already been
proposed. It seemed pretty clear to everyone that this change was
required in order for SETF of macros to work properly, so a number of
implementations went ahead and added it (as an optional arg), even
though there has been no mechanism whereby this change could be adopted
officially.
-- Scott
∂22-Nov-86 2054 RPG GET-SETF-METHOD
To: common-lisp@SAIL.STANFORD.EDU
This issue comes up every 6-12 months. Most recently, on December 13,
1985, Steele proposed a clarification, which he lists as `serious':
(*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do
not perform macro-expansion on the given form, and that in most contexts
the usage should be (GET-SETF-METHOD (MACROEXPAND form env)). Indeed,
the simplified example version of SETF given on page 108 should be
changed to: <you don't want to see it>
Nine hours and 31 minutes later, Rob MacLachlan pointed out that this
would not work because of setf methods.
Two days, 11 hours, and 49 minutes later, Steele agreed.
In the meantime, on December 14, 1985, Eric Benson pointed out that
DEFINE-SETF-METHOD also needed an environment passed. On July 19 Plummer
noticed it himself, and MacLachlan affirmed this observation.
Several vendors made the change because it seemed a clear case of a
mistake in the language rather than a clarification.
I would say that VaxLisp and ExCL are not in error, but the usefulness
of MACROLET is limited without this change.
-rpg-
∂23-Nov-86 1236 RAM@C.CS.CMU.EDU (typep 3 'complex) => t
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 86 12:36:25 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 23 Nov 86 15:36:20-EST
Date: Sun, 23 Nov 1986 15:36 EST
Message-ID: <RAM.12257292060.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SU-AI.ARPA
Subject: (typep 3 'complex) => t
There is a bit of type sysem lossage that I noticed lately which is
unrelated to the TYPE-OF discussion. My realization is that RATIONAL
is a subtype of (COMPLEX NUMBER), since according to p47, "...this
type encompasses those complex numbers that can result from giving
numbers of the specified type to the function COMPLEX." Of course,
(COMPLEX 3 0) => 3.
This interpretation depends on the meaning of the phrase "complex
numbers" in the above passage. This interperetation does not hold if
"complex number" in the above passage means a number where
(NOT (EQL (IMAGPART number) 0)).
Due to the rule for complex canonicalization, it makes no sense to
require the non-0 imagpart, since it makes the declaration useless
for complex numbers with rational components.
It seems that there is an analogy between COMPLEX and RATIONAL due to
the similarity of the complex and rational canonicalization rules. 3
is a rational, since a rational can be canonicalized to an integer.
Similarly, 3 is a complex since a complex can be canonicalized to an
integer. The real problem is that there is no type which is to
COMPLEX as RATIO is to RATIONAL, i.e. a type that represents complex
numbers that have not been canonicalized.
If my intepretation is correct, then the COMPLEX type with no
component type specified is effectively equivalent to
(AND NUMBER (NOT FLOAT)). This makes the COMPLEXP function fairly
useless if it continues to be equivalent to (TYPEP ... 'COMPLEX).
There is some mumbling about "may be different for declaration and
discrimination" in the definition of the COMPLEX type specifier, but
close reading suggests that this is irrelevant to the issue at hand,
since it is really attempting to say that COMPLEX types are similar to
ARRAY types in that the implementation has freedom in choosing
component type specializations. Comparison with the similar hemming
and hawing in the ARRAY definition supports this conclusion.
Rob
∂23-Nov-86 1413 Masinter.pa@Xerox.COM Re: (typep 3 'complex) => t
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 86 14:13:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 86 14:13:43 PST
Date: 23 Nov 86 14:13 PST
From: Masinter.pa@Xerox.COM
Subject: Re: (typep 3 'complex) => t
In-reply-to: Rob MacLachlan <RAM@C.CS.CMU.EDU>'s message of Sun, 23 Nov
86 15:36 EST
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <861123-141343-2764@Xerox>
I'd thought all along that the COMPLEX type was intended to be the
analog of RATIO, and not include those numbers which canonicalized to
RATIONAL. Your message seems to assert that the description on p 47
implies otherwise, but it seems more reasonable that this is just a case
of ambiguous wording.
You claim "Due to the rule for complex canonicalization, it makes no
sense to require the non-0 imagpart, since it makes the declaration
useless for complex numbers with rational components."
But it does make sense, and such declarations are useful, (well, as
useful as RATIO declarations) for example:
(typecase x
(rational ... )
(complex (locally (declare (type complex x)) ...)
...)
where one could assume within the scope of the declaration that realpart
and imagpart could be optimized, for example.
∂23-Nov-86 1432 RAM@C.CS.CMU.EDU (typep 3 'complex) => t
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 86 14:32:45 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 23 Nov 86 17:32:41-EST
Date: Sun, 23 Nov 1986 17:32 EST
Message-ID: <RAM.12257313244.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: common-lisp@SU-AI.ARPA
Subject: (typep 3 'complex) => t
In-reply-to: Msg of 23 Nov 1986 17:13-EST from Masinter.pa at Xerox.COM
But under my interpretation, (DECLARE (COMPLEX FIXNUM)) would be
much more useful, since the it would be a declaration that the user
could reasonably make, yet would give the system the useful
information that both the realpart and imagpart are fixnums. In this
case, the compiler could reasonably store the realpart and imagpart as
separate fixnums, and would only have to canonicalize them when it is
forced to pointerize the number.
In the case of a float component type, there is no difference in
the results of the two interpretations, since complex float types are
not canonicalized. I think that the definition of complex rational
types was not thoroughly thought out due to their novelty.
If there were no RATIONAL type, then it would make sense to argue
that COMPLEX should be useless by analogy with RATIO, but if we are
trying to provide a useful type system, then it is silly.
Perhaps COMPLEX should remain what everyone thought it was, but
there is definitely a need for the type that I think COMPLEX ought to
be. I think that there is a strong argument that my interpretation
should get the "good" name, since it is what people will usually want
to use.
Rob
∂23-Nov-86 1538 Masinter.pa@Xerox.COM Re: (typep 3 'complex) => t
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 86 15:38:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 86 15:38:36 PST
Date: 23 Nov 86 15:38 PST
From: Masinter.pa@Xerox.COM
Subject: Re: (typep 3 'complex) => t
In-reply-to: Rob MacLachlan <RAM@C.CS.CMU.EDU>'s message of Sun, 23 Nov
86 17:32 EST
To: RAM@C.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
Message-ID: <861123-153836-2807@Xerox>
why don't you use
(deftype complex-number (&optional type)
(if type `(or ,type (complex ,type))
'(or rational complex)))
e.g., (declare (type complex-number x))
means that either X is strictly complex or else a rational, while
(declare (type (complex-number fixnum) x)
means that either X is a fixnum or a (complex fixnum).
It seems well within the bounds of the Common Lisp framework to use
deftype to add types that are interesting to some compilers, without
requiring that the types be added to every other implementation.
∂24-Nov-86 1135 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU question: EVAL
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86 11:34:50 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 18517; 24 Nov 86 13:57:23-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 44996; Fri 21-Nov-86 11:39:30-EST
Date: Fri, 21 Nov 86 11:39 est
Sender: mike@acorn
To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET
From: mike%gold-hill-acorn@mit-live-oak.arpa
Subject: question: EVAL
Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET
Date: Fri, 21 Nov 86 17:49:44+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
In the list of GLS, there is an EVAL extension to have an optional argument
for 'environment'.
will it be defined in the comming specification ?
Is this only one argument ?
Does the value of this optional 'environmental' argument have a defined
syntax/semantics ?
ida
I have no qualms at all about adding the ability to address the
current macro-expansion environment, and to pass it to eval. I have
real difficulty with the ability to pass the complete lexical
environment.I think the issue of whether to add complete environments
for eval is one of the more controvercial ones in "the list of GLS".
Having the ability to pass a lexical environment assumes the
ability to access the lexical environment. There is currently
no way to access this, it is implicitly passed by eval to
evalhooks, and so on. Let me assume that you also want a way
to access the current lexical environment, say by a function
(get-current-env).
I think any code which uses this environment would be impossible to
compile, in the sense that the compiler probably couldn't do much
with it. This would hold for the entire body of lexically surrounding
code. For example:
(defun wierd-function (s-expression)
(block here
(tagbody :tag
(let ((x (foo s-expression)))
(labels ((bar (y) (+ x y)))
(eval s-exp (get-current-env)))))))
The s-expression could draw on any of the environment here, so
we can't optimize anything out of the environment. We can achieve
the desired effect by writing:
(defun wierd-function (s-expression)
(eval `(block here
(tagbody :tag
(let ((x (foo s-expression)))
(labels ((bar (y) (+ x y)))
,@s-exp))
Which is probably just about as good as the compiler could do anyway
and doesn't use any environments.
...mike beckerle
Gold Hill Computers
∂24-Nov-86 1300 sandra%utah-orion@utah-cs.arpa hash table question
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86 12:59:06 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA19611; Mon, 24 Nov 86 14:00:13 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA21161; Mon, 24 Nov 86 14:00:10 MST
Date: Mon, 24 Nov 86 14:00:10 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8611242100.AA21161@utah-orion.ARPA>
Subject: hash table question
To: common-lisp@su-ai.arpa
Is hashing supposed to "work" if destructive operations are performed on
the hashed object, or is the hash index computed for an object a function
of what's "in" the object rather than the object itself? As an example,
does this bit of code always return true?
(let* ((cons (cons 'a 'b))
(before (sxhash cons))
(after (sxhash (rplaca cons 'foobar))))
(eql before after))
-Sandra
-------
∂24-Nov-86 1543 DLW@ALDERAAN.SCRC.Symbolics.COM hash table question
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 24 Nov 86 15:43:14 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23873; Mon 24-Nov-86 18:41:14 EST
Date: Mon, 24 Nov 86 18:39 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: hash table question
To: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <8611242100.AA21161@utah-orion.ARPA>
Message-ID: <861124183912.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
No, it doesn't always return true. sxhash is an "equal" hash, returning
the same value for equal structures, even if they're not eq. So the
idea is that it does a tree walk and computes its number out of what it
finds in the leaves. Since you've changed a leaf and it is no longer
"equal" to what it used to be, it can have a new sxhash value, and
probably does. This could have been spelled out in more detail in CLtL.
∂24-Nov-86 1630 sandra%utah-orion@utah-cs.arpa Re: hash table question
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86 16:30:28 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA28782; Mon, 24 Nov 86 17:31:32 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA22562; Mon, 24 Nov 86 17:31:28 MST
Date: Mon, 24 Nov 86 17:31:28 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8611250031.AA22562@utah-orion.ARPA>
Subject: Re: hash table question
To: Daniel L. Weinreb <DLW@alderaan.scrc.symbolics.com>
Cc: sandra%utah-orion@utah-cs.arpa, common-lisp@su-ai.arpa
In-Reply-To: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>, Mon, 24 Nov 86 18:39 EST
Date: Mon, 24 Nov 86 18:39 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
No, it doesn't always return true. sxhash is an "equal" hash, returning
the same value for equal structures, even if they're not eq.
Fine. So what happens if the cons I just clobbered was being used as a
key in an "eq" hash table? Certainly the original cons is still "eq" to
itself after it's been clobbered. Does this mean that an "eq" hash table
*can't* look at the contents of an object to compute a hash index?
(Actually, I can't think of any reason why one would *want* to perform
destructive operations on an object that is being used as a hash key, and
would be happy to see this made "an error".)
-Sandra
-------
∂24-Nov-86 1725 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: hash table question
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86 17:24:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 8947; Mon 24-Nov-86 20:21:45 EST
Date: Mon, 24 Nov 86 20:21 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: hash table question
To: Sandra J Loosemore <sandra%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8611250031.AA22562@utah-orion.ARPA>
Message-ID: <861124202145.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 24 Nov 86 17:31:28 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Date: Mon, 24 Nov 86 18:39 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
No, it doesn't always return true. sxhash is an "equal" hash, returning
the same value for equal structures, even if they're not eq.
Fine. So what happens if the cons I just clobbered was being used as a
key in an "eq" hash table? Certainly the original cons is still "eq" to
itself after it's been clobbered. Does this mean that an "eq" hash table
*can't* look at the contents of an object to compute a hash index?
(Actually, I can't think of any reason why one would *want* to perform
destructive operations on an object that is being used as a hash key, and
would be happy to see this made "an error".)
Suppose you're doing object-oriented programming, and you're an old-line
Lisp type who didn't make it past chapter 16 of CLtL, so you're
implementing your objects as conses. Suppose the car of each cons is the
class, while the cdr of each cons is a property-list containing the local
state. Then it would be quite reasonable to simultaneously use these
objects as :test 'eq hash-table keys and to perform destructive operations
on them. The hashing, with :test 'eq, is using the object's identity as
the key, not using the object's contents as the key.
Thus I think the answer is that an "eq" hash table must not look at the
contents of an object when it hashes. This could all be explained a whole
lot better in the manual (although the language on p.282, distinguishing
tables that hash on objects from tables that hash on tree structure, was
probably intended to be the explanation of this.)
∂24-Nov-86 1959 FAHLMAN@C.CS.CMU.EDU hash table question
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86 19:59:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 24 Nov 86 22:58:59-EST
Date: Mon, 24 Nov 1986 22:58 EST
Message-ID: <FAHLMAN.12257634784.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sandra%utah-orion@λutah-cs.arpa (Sandra J Loosemore)λ
Cc: common-lisp@SU-AI.ARPA
Subject: hash table question
In-reply-to: Msg of 24 Nov 1986 16:00-EST from sandra%utah-orion at utah-cs.arpa (Sandra J Loosemore)
The hashing obviously will be messed up if you make destructive changes
that would alter the key under which things are hashed. If you have
things stored in an EQ hash table and you change the datum in such a way
that the resulting objects are still EQ, things should still work.
Ditto if you have a EQUAL hash-table and change an entry in some way
that leaves it EQUAL to what it was before. But if you sneak in and
change some list element from 3 to 'foo, the datum would no longer be
hashed properly and you can only win if you remove the datum and then
re-enter it into the hash-table.
-- Scott
∂24-Nov-86 2130 edsel!bhopal!jonl@navajo.stanford.edu type-of
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86 21:30:39 PST
Received: by navajo.stanford.edu; Mon, 24 Nov 86 21:28:23 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA18138; Mon, 24 Nov 86 19:37:15 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA05882; Mon, 24 Nov 86 19:36:21 PST
Date: Mon, 24 Nov 86 19:36:21 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8611250336.AA05882@bhopal.edsel.uucp>
To: navajo!sandra%utah-orion%utah-cs.arpa@navajo.stanford.edu
Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu
In-Reply-To: navajo!sandra%utah-orion@utah-cs.arpa's message of Wed, 19 Nov 86 09:11:01 MST
Subject: type-of
I had once thought of using TYPE-OF in the situation where I knew something
was a defstruct, but didn't know it's name/type; however, just knowing that
something is an instance of a defstruct isn't a portable question right now.
Wasn't there a suggestion some time ago to have a new primitive function
(or functions) for asking just these kinds of questions; i.e., is an object
an instance of a structure defined without the :type option? and if so, what
is its type name?
-- JonL --
∂24-Nov-86 2134 edsel!bhopal!jonl@navajo.stanford.edu hash table question
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86 21:34:10 PST
Received: by navajo.stanford.edu; Mon, 24 Nov 86 21:31:53 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA18149; Mon, 24 Nov 86 19:39:31 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA05886; Mon, 24 Nov 86 19:38:38 PST
Date: Mon, 24 Nov 86 19:38:38 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8611250338.AA05886@bhopal.edsel.uucp>
To: navajo!sandra%utah-orion%utah-cs.arpa@navajo.stanford.edu
Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu
In-Reply-To: navajo!sandra%utah-orion@utah-cs.arpa's message of Mon, 24 Nov 86 14:00:10 MST
Subject: hash table question
SXHASH has the contract of returning the same value on things that
"print alike". This is implicit in the definition of sxhash that says:
"(equal x y) implies (= (sxhash x) (sxhash y))". [See CLtL p285; also
the rule-of-thumb definition of EQUAL on p80.]
In your example, you have two items which are EQ but not EQUAL [wait,
read the rest before you judge this a contradiction]. Since they are
not equal, you can't expect them to have the same sxhash values.
The "two items" involved are two readings of the same "memory cell" at
different times. Since it is "the same memory cell", the two items are
EQ; but since an intrusive update occured during the time between the
the two readings, "they" are no longer equal.
I find it somewhat curious that the following dumb definition perfectly
satisfies CLtL's requirements for SXHASH:
(defun sxhash (x) 5)
and this definition would give you the before/after equivalence you are
asking about. How SXHASH differs fundamentally from the non-Common-Lisp
function %POINTER available in ZetaLisp (or the LOC in Interlisp) is that
it must be independent of the address of a "memory cell", if any, holding
the object. CLtL tries to say this with language like "incarnation" and
"core image". But, note how well the above dumb definition of sxhash
satisfies this independence criterion!
On the other hand, 5 really isn't a very good hashing function. It would
give very poor distribution if it were the basis of gethash -- all entries
would be in the same collision chain -- so it seems reasonable to descend
into structures, even updatable structures, and compute a value that is,
by design, potentially different after the object is updated. The value
returned by %POINTER (and LOC) wouldn't be affected by the RPLACA in your
example, but they have other problems:
(1) they don't have the "equal[x,y] ==> sxhash[x] = sxhash[y]" property
mentioned above, and
(2) they don't remain the same over a relocating gc or a generational
scavenge.
If your point in asking this question is to examine the semantics of
EQ-type hash tables, then I think there is general consensus that
EQ-type tables don't simply mean that the "test" is EQ (as opposed
to EQUAL), but that the collision chains are based upon the object
"address" rather than the object "contents". EQ-testing hash tables
with collision chains built the other way are certainly conceivable,
but one wonders what value they would be. As I surmised in a previous
note to this community, there is an unfortunate tendency to think that
EQ-tables are "much faster" than EQUAL-tables, and the semantically
wrong choice of :test is often made because of a mistaken conception
about performance. [A typical place where EQ-type tables *are* indeed
the correct choice is in circularity detection, or possibly in macro-
expansion caches like MACROMEMO of MacLisp and CLISPARRAY of Interlisp].
This may also explain why there hasn't been a greater interest in
opening up an independent :sxhash argument to MAKE-HASH-TABLE; EQ-type
tables are only really useful when it is the "address" of the key
that is important (rather than its contents), so suppying some other
:sxhash argument wouldn't be as useful as the built-in %POINTER. Also,
most people are reluctant to admit %POINTER/LOC as a primitive in the
language since it is so deeply affected by memory-management strategy.
-- JonL --
∂25-Nov-86 2005 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU EVAL
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 86 20:05:28 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 19003; 25 Nov 86 19:02:40-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 45101; Tue 25-Nov-86 02:35:23-EST
Date: Tue, 25 Nov 86 02:36 est
Sender: mike@acorn
To: Alan@AI.AI.MIT.EDU
From: mike%acorn@mit-live-oak.arpa
Subject: EVAL
Cc: Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU,
common-lisp@SU-AI.ARPA
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
Date: Thu, 20 Nov 1986 16:19 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
EVAL cannot easily be defined to work in the lexical environment in
which it appears because that lexical environment is not around at
runtime,....
Right. This demonstrates that LEXICAL-EVAL would have to be a new special
form, rather than simply a function.
This same issue seems to come up over and over. Will someone tell
me what is wrong with the following argument:
I see no reason for "lexical-eval" or any eval with an environment arg.
The following is a trivial source-to-source you can use to get the
effect of a lexical eval:
Suppose you wanted
(defun foo (s-exp)
(let ((x 5))
(flet ((bar (y) (+ x y)))
(block here
(tagbody :there
(lexical-eval s-exp))))))
this is exactly equivalent to:
(defun foo (s-exp)
(eval
`(let ((x 5))
(flet ((bar (y) (+ x y)))
(block here
(tagbody :there
,s-exp))))))
which does not use any "lexical-eval". Since the primary
effect of the compiler is to eliminate lexical environments, any
lexical "stuff" surrounding a call to "lexical-eval" can't really
be compiled (not much anyway) since it all might be referred to
by the s-expression being evaled. This being the case, the
second form here, which just eval's the entire lexical scope,
is roughly as efficient.
...mike beckerle
Gold Hill Computers.
∂25-Nov-86 2124 ALAN@AI.AI.MIT.EDU EVAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 86 21:24:09 PST
Date: Wed, 26 Nov 86 00:24:12 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: EVAL
To: mike%acorn@LIVE-OAK.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU,
Sean.Engelson@CAD.CS.CMU.EDU
In-reply-to: Msg of Tue 25 Nov 86 02:36 est from mike%acorn at mit-live-oak.arpa
Message-ID: <123570.861126.ALAN@AI.AI.MIT.EDU>
Date: Tue, 25 Nov 86 02:36 est
From: mike%acorn at mit-live-oak.arpa
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
... This demonstrates that LEXICAL-EVAL would have to be a new
special form, rather than simply a function.
This same issue seems to come up over and over. Will someone tell
me what is wrong with the following argument:...
I'm not quite sure what your proposed source transformation was supposed to
demonstrate. How do you compile
(defun bind-x-then-call-f (x f)
(funcall f `(cons x x)))
given that anyone can do
(bind-x-then-call-f 'foo #'lexical-eval)?
∂26-Nov-86 0834 KMP@YUKON.SCRC.Symbolics.COM EVAL
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Nov 86 08:34:07 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126346; Wed 26-Nov-86 11:31:57 EST
Date: Wed, 26 Nov 86 11:31 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: EVAL
To: ALAN@AI.AI.MIT.EDU
cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA,
Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU
In-Reply-To: <123570.861126.ALAN@AI.AI.MIT.EDU>
Message-ID: <861126113148.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 26 Nov 86 00:24:12 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: EVAL
To: mike%acorn@LIVE-OAK.LCS.MIT.EDU
cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU,
Sean.Engelson@CAD.CS.CMU.EDU
In-reply-to: Msg of Tue 25 Nov 86 02:36 est from mike%acorn at mit-live-oak.arpa
Message-ID: <123570.861126.ALAN@AI.AI.MIT.EDU>
Date: Tue, 25 Nov 86 02:36 est
From: mike%acorn at mit-live-oak.arpa
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
... This demonstrates that LEXICAL-EVAL would have to be a new
special form, rather than simply a function.
This same issue seems to come up over and over. Will someone tell
me what is wrong with the following argument:
I see no reason for "lexical-eval" or any eval with an environment arg.
The following is a trivial source-to-source you can use to get the
effect of a lexical eval:
Suppose you wanted
(defun foo (s-exp)
(let ((x 5))
(flet ((bar (y) (+ x y)))
(block here
(tagbody :there
(lexical-eval s-exp))))))
this is exactly equivalent to:
(defun foo (s-exp)
(eval
`(let ((x 5))
(flet ((bar (y) (+ x y)))
(block here
(tagbody :there
,s-exp))))))
which does not use any "lexical-eval". Since the primary
effect of the compiler is to eliminate lexical environments, any
lexical "stuff" surrounding a call to "lexical-eval" can't really
be compiled (not much anyway) since it all might be referred to
by the s-expression being evaled. This being the case, the
second form here, which just eval's the entire lexical scope,
is roughly as efficient.
No, it's -roughly- equivalent to:
(defun foo (s-exp)
(eval `(let ((s-exp ',s-exp))
(let ((x 5))
(flet ((bar (y) (+ x y)))
(block here
(tagbody :there ,s-exp)))))))
and even then it doesn't address the issue of what happens if S-EXP
contains code that destructively modifies the list structure in the
object held by S-EXP. My rewrite, which at least appropriately binds
the variable S-EXP, makes that be well-behaved, which is not a
semantics-preserving transformation.
I'm not quite sure what your proposed source transformation was supposed to
demonstrate. How do you compile
(defun bind-x-then-call-f (x f)
(funcall f `(cons x x)))
given that anyone can do
(bind-x-then-call-f 'foo #'lexical-eval)?
Right. Your remark about how this could be done as a special form
thwarts the ability to do this (since you can't do #'<special-form>)
and hides the potential problem in a fortuitous way. The real issue,
of course, is that this is the power people -want-. They want things
like EVAL-IN-CLOSURE, which are the problemsome cases, because the
introduction of such into the language ties the hands of the compiler
and doesn't allow any optimization.
I think Mike's intent is correct, though, in that the situations where
you might want LEXICAL-EVAL in cases that are constrained adequately so
as not to break the language are handled adequately by his suggested
rewrite using EVAL. The cases that are not handled by that rewrite --
and not at all by coincidence -- are the cases which strike fear in the
hearts of compiler maintainers everywhere.
Moreover, using LEXICAL-EVAL invites many of the name collision problems
that the move to lexical scoping did away with.
(DEFUN F (X Y) (+ X (EVAL Y)))
used to be a problem in dynamic lisps because the local X and Y would
interfere with the EVAL (at least in the interpreter and also in some
compilers). In a lexical Lisp, such as CL, the name collision problem
doesn't happen. Allowing people to do LEXICAL-EVAL there is just asking
for the same unwanted name collisions that we were trying to get away
with in CL.
I concur with those who have said we should explicitly document the
rationale for the absence of this primitive in the next CL language spec.
∂26-Nov-86 0834 spe@cad.cs.cmu.edu Re: EVAL
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Nov 86 08:34:05 PST
Date: 26 Nov 1986 11:29-EST
From: Sean.Engelson@cad.cs.cmu.edu
To: Alan Bawden <ALAN@AI.AI.MIT.EDU>
cc: common-lisp@su-ai.arpa
Subject: Re: EVAL
Message-Id: <533406551/spe@cad.cs.cmu.edu>
In-Reply-To: Alan Bawden's mail message of Wed, 26 Nov 86 00:24:12 EST
>Date: Wed, 26 Nov 86 00:24:12 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: EVAL
I'm not quite sure what your proposed source transformation was supposed to
demonstrate. How do you compile
(defun bind-x-then-call-f (x f)
(funcall f `(cons x x)))
given that anyone can do
(bind-x-then-call-f 'foo #'lexical-eval)?
Yes, but given lexical-eval as a special form, you couldn't do that.
Perhaps lexical-eval could substitute lexical values for the variables
in its argument, then eval the result?
-Sean-
∂26-Nov-86 1308 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU eval and other topics
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 26 Nov 86 13:07:58 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2622; 26 Nov 86 15:49:21 EST
Date: Wed, 26 Nov 86 15:50 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: eval and other topics
To: common-lisp@su-ai.arpa
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <861126155002.1.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@ACORN.CS.ROCHESTER.EDU
Reply-To: miller@ACORN.CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
A large number of arguments against doing feature X for a while have been
along the lines of:
We shouldn't do feature X because then the compiler becomes harder, and
couldn't optimize the code as much.
While this may certainly be true (though it is more likely that the compiler
would have to detect the use of feature X and THEN not optimize the code as
much), I think it completely avoids the much deeper issue.
I am a user of lisp. I am not a compiler writer (now). I don't CARE if such
and so is easily compilable. I use lisp because it lets me express my ideas
more easily than other languages do. If we stifle the growth of CL toward the
lisp USER's needs, we will have a very fast, very compilable language that no
one will want to use.
I think that the questions that need to be asked when feature X is proposed is
1) is it a real problem? is there a simple mechanism that already exists to
address the problem? If the proposal is syntactic sugar is it of the form that
will allow program writers greater perspicuity?
2) does the proposed solution actually address the problem generically, or
does it only address some instance?
3) can the solution be implemented at all?
4) is it reasonably upwards-compatible with the existing language? (not
necessarily existing implementations). If not, is the scope of the change
relatively small (will not require substantial rewrite of existing USER code,
and/or the rewrite involved could be handled via a simple text
transformation).
5) has the proposed solution actually been tried? Has it actually helped users
who have run accross the problem? Does it otherwise constrain them? Is it
intuitive? (i.e. is it something that seems to "fit" the language - nebulous I
know, but this is an intuitive description too. Something like is it in the
style of Lisp.)
If the answers to the above are satisfactory, then I think there is a
reasonably good case for adding the feature to the language. Minor
difficulties like requiring smarter compilers, substantial rewrites to
existing compilers, etc. is a complete side issue, I think. Mostly because if
adding feature X allows a reasonable increase in USER productivity, who cares
how much time it takes the COMPILER writer to implement it - that time is
amortized over all the users who are now saving time with the new feature (or
at least able to express themselves more clearly in CL, or whatever).
Flames? Comments?
Brad Miller
PS: I bring this up because I mentioned the EVAL thing privately to Fahlman a
few months ago back when he was controlling new discussion, and basically got
back his original posting on the subject. While I certainly concur that a
lexical eval is not a particularly good idea as far as a compiler writer is
concerned (because it is very hard, and very inefficient), I think it is a
TERRIFIC idea for USERS. I've needed the functionality several times, and each
workaround is a total hack that has to be explaned in about a page of extra
documentation so the next poor slob that has to maintain my code can figure
out why I wrote such dreadful code in the first place (and what it does).
------
miller@rochester.arpa
miller@ur-acorn.arpa
∂26-Nov-86 1407 @WAIKATO.S4CC.Symbolics.COM:KMP@STONY-BROOK.SCRC.Symbolics.COM eval and other topics
Received: from [128.81.51.90] by SAIL.STANFORD.EDU with TCP; 26 Nov 86 14:06:58 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77582; Wed 26-Nov-86 17:05:04 EST
Date: Wed, 26 Nov 86 17:04 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: eval and other topics
To: miller@ACORN.CS.ROCHESTER.EDU
cc: kmp@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA
In-Reply-To: <861126155002.1.MILLER@CASHEW.CS.ROCHESTER.EDU>
Message-ID: <861126170437.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 26 Nov 86 15:50 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
... While I certainly concur that a lexical eval is not a particularly good
idea as far as a compiler writer is concerned (because it is very hard, and
very inefficient), I think it is a TERRIFIC idea for USERS. I've needed the
functionality several times, and each workaround is a total hack that has to be
explained in about a page of extra documentation so the next poor slob that has
to maintain my code can figure out why I wrote such dreadful code in the first
place (and what it does). ...
I (and I'm sure others on this list) would be very interested to see a sketch,
explanation, or example of a place where you think LEXICAL-EVAL was essential.
Personally, I can think of no places (other than in debuggging or situations
closely related to debugging) where it was either essential or even appropriate.
I seriously doubt that I can be convinced that it is a "terrific" idea for
users in any case. The whole point of lexicality is to allow static analysis.
The whole-point of LEXICAL-EVAL is to allow a Turing-powerful piece of code
to modify the lexical environment in arbitrary ways, potentially thwarting
many (probably most) useful kinds of static analysis which one might contemplate.
The compiler is not pathological here -- any tool which tried to do program
understanding (including macros, translators, optimizers, and human programmers)
would have to expect trouble in the face of this primitive. I don't find this
prospect "terrific".
∂26-Nov-86 1734 ALAN@AI.AI.MIT.EDU EVAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Nov 86 17:34:07 PST
Date: Wed, 26 Nov 86 20:34:26 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: EVAL
To: common-lisp@SU-AI.ARPA
Message-ID: <123881.861126.ALAN@AI.AI.MIT.EDU>
Date: 26 Nov 1986 11:29-EST
From: Sean.Engelson at cad.cs.cmu.edu
Date: Wed, 26 Nov 86 00:24:12 EST
From: Alan Bawden <Alan at AI.AI.MIT.EDU>
... How do you compile...
Yes, but given lexical-eval as a special form, you couldn't do that.
Which is exactly why my original message said:
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan at AI.AI.MIT.EDU>
... This demonstrates that LEXICAL-EVAL would have to be a new
special form, rather than simply a function.
Perhaps lexical-eval could substitute lexical values for the variables
in its argument, then eval the result?
Perhaps it could use the more or less the same evaluator the interpreter
uses, passing it an environment constructed by the compiler from the
lexically apparent entities surrounding the occurrence of the LEXICAL-EVAL
form.
In painful detail:
(defmacro lexical-eval (foo)
`(sys:internal-lexical-eval ,foo (sys:the-surrounding-lexical-environment)))
Where SYS:INTERNAL-LEXICAL-EVAL is an ordinary function that is an
implementation dependent entry into the interpreter, and
SYS:THE-SURROUNDING-LEXICAL-ENVIRONMENT is a special form that causes the
compiler to create and return an implementation dependent datastructure
that the interpreter can use to access the variables, block names, tagbody
tags, and macro definitions apparent at that location.
It is -incorrect- that an occurrence of LEXICAL-EVAL hopelessly cripples the
compiler's ability to compile the surrounding code. A possible expansion
of (SYS:THE-SURROUNDING-LEXICAL-ENVIRONMENT) might be:
(list (list :read 'x (lambda () x))
(list :setq 'x (lambda (v) (setq x v)))
(list :read 'y (lambda () y))
(list :setq 'y (lambda (v) (setq y v)))
(list :return-from 'top (lambda (v) (return-from top v)))
(list :go 'loop (lambda () (go loop))))
where X and Y are the lexically apparent variables, and TOP and LOOP are
the lexically apparent block names and tagbody tags respectively. This
datastructure would give the interpreter all the access it needs to the
environment in question. I hope that most Common Lisp compilers can
-already- successfully compile the above expression.
Yes, I have ignored a couple of issues here (like the representation of the
macro definition environment, and the possibility of returning multiple
values from a block), but I don't see any fatal flaws, only complications
that don't belong in a brief message.
I'm still not advocating anything, I'm just trying to make sure we all know
what we are flaming about.
∂28-Nov-86 1341 @MIT-LIVE-OAK.ARPA:mike@GOLD-HILL-ACORN.LCS.MIT.EDU EVAL
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 86 13:41:19 PST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 19439; 28 Nov 86 16:30:19-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 45600; Wed 26-Nov-86 11:09:57-EST
Date: Wed, 26 Nov 86 11:10 est
Sender: mike@acorn
To: ALAN@AI.AI.MIT.EDU
From: mike%acorn@mit-live-oak.arpa
Subject: EVAL
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA,
Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU
Date: Wed, 26 Nov 86 00:24:12 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Date: Tue, 25 Nov 86 02:36 est
From: mike%acorn at mit-live-oak.arpa
Date: Sat, 22 Nov 86 17:32 EST
From: Alan Bawden <Alan@AI.AI.MIT.EDU>
... This demonstrates that LEXICAL-EVAL would have to be a new
special form, rather than simply a function.
This same issue seems to come up over and over. Will someone tell
me what is wrong with the following argument:...
I'm not quite sure what your proposed source transformation was supposed to
demonstrate. How do you compile
(defun bind-x-then-call-f (x f)
(funcall f `(cons x x)))
given that anyone can do
(bind-x-then-call-f 'foo #'lexical-eval)?
I just write
(defun bind-x-then-call-f (x f)
(eval `(funcall ,f '(cons ,x ,x)))
and do this
(bind-x-then-call-f 'foo #'eval)
instead, which is to say I don't bother compiling it at all.
I see no difference semantically here. Is there a
tougher example, possibly involving closures?
... mike beckerle.
∂30-Nov-86 0026 ALAN@AI.AI.MIT.EDU EVAL
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 86 00:26:49 PST
Date: Sun, 30 Nov 86 03:26:23 EST
From: Alan Bawden <ALAN@AI.AI.MIT.EDU>
Subject: EVAL
To: Common-Lisp@SU-AI.ARPA
In-reply-to: Msg of Wed 26 Nov 86 11:10 est from mike%acorn at mit-live-oak.arpa
Message-ID: <124500.861130.ALAN@AI.AI.MIT.EDU>
Date: Wed, 26 Nov 86 11:10 est
From: mike at acorn
Date: Wed, 26 Nov 86 00:24:12 EST
From: Alan Bawden <ALAN at AI>
... How do you compile
(defun bind-x-then-call-f (x f)
(funcall f `(cons x x)))...
I just write
(defun bind-x-then-call-f (x f)
(eval `(funcall ,f '(cons ,x ,x)))...
I presume you mean this to be
(defun bind-x-then-call-f (x f)
(eval `(funcall ',f '(cons ',x ',x)))).
The quotes prevent an extra evaluation I doubt you intended.
You can't rewrite BIND-X-THEN-CALL-F this way because before your rewrite
it was the case that:
(bind-x-then-call-f 7 #'cadr) ==> X
but afterwords:
(bind-x-then-call-f 7 #'cadr) ==> (QUOTE 7)
∂01-Dec-86 0954 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU eval and other topics
Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 86 09:53:55 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2690; 1 Dec 86 12:51:52 EST
Date: Mon, 1 Dec 86 12:53 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: eval and other topics
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
cc: Common-Lisp@SU-AI.ARPA, miller@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <861126170437.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <861201125315.0.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@ACORN.CS.ROCHESTER.EDU
Reply-To: miller@ACORN.CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Date: Wed, 26 Nov 86 17:04 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Date: Wed, 26 Nov 86 15:50 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
... While I certainly concur that a lexical eval is not a particularly good
idea as far as a compiler writer is concerned (because it is very hard, and
very inefficient), I think it is a TERRIFIC idea for USERS. I've needed the
functionality several times, and each workaround is a total hack that has to be
explained in about a page of extra documentation so the next poor slob that has
to maintain my code can figure out why I wrote such dreadful code in the first
place (and what it does). ...
I (and I'm sure others on this list) would be very interested to see a sketch,
explanation, or example of a place where you think LEXICAL-EVAL was essential.
Personally, I can think of no places (other than in debuggging or situations
closely related to debugging) where it was either essential or even appropriate.
[....]
Well, it's been a while since I gave up on doing things that way, so I don't
have any code handy, but the idea was that given lexical scoping, one can then
define functions with precisely defined scope rules, e.g. using flet. However,
once I had defined these functions, I could not use eval on them, since they
were invisible to the dynamic environment. The details of why I was trying to
do this (seemingly) reasonable thing are hazy, but as I recall in one case,
there were some functions (axioms for a horne clause theorem prover) that were
evaluated normally by some routines that would 'interpret' the language by
calling the routines by prefixing them with a string (to prevent name
conflicts with CL functions). This was the hack - the better solution was to
temporarily redefine these functions using flet so the threaded language could
be interpreted directly, without globally redefining the lisp function. Since
which function had to be called varied somewhat by context (modeled by which
function actually did the interpretation) the same name could serve for each
of these flets - since lexical scoping would not be ambiguous. Instead, with
all functions globably defined, different strings were hacked into the
pseudo-function call names, and then the (new) lisp stream could be eval'd.
There may well be a better hack than this (actually, I'm not the one who ended
up writing it, but I suppose I am responsible for it), however, I don't think
anything might have surpassed the simple and clean elegance of a lexical-eval.
Brad Miller
------
miller@rochester.arpa
miller@ur-acorn.arpa
∂01-Dec-86 1239 spe@cad.cs.cmu.edu Packages
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 12:39:12 PST
Date: 1 Dec 1986 15:34-EST
From: Sean.Engelson@cad.cs.cmu.edu
To: common-lisp@su-ai
Subject: Packages
Message-Id: <533853280/spe@cad.cs.cmu.edu>
This idea has probably been brought up before, but as a solution to the
'packages problem', without really any loos of functionality, I propose
the following: To have symbols be universal, but their values and
function definitions (maybe extended to all properties) be
package-tied. Thus symbols are symbols and are EQ to each other in all
the expectable cases, etc.., but we have the functionality of differing
name spaces. This could be implemented by having a PACKAGE 'property'
attached to different values of a symbol's property..
∂01-Dec-86 1326 @MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA Packages
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 13:26:26 PST
Received: from CHERRY.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 19829; Mon 1-Dec-86 16:25:08-EST
Date: Mon, 1 Dec 86 16:25 EST
From: Soley@MIT-XX.ARPA
Subject: Packages
To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <533853280/spe@cad.cs.cmu.edu>
Message-ID: <861201162542.1.SOLEY@CHERRY.LCS.MIT.EDU>
Date: 1 Dec 1986 15:34-EST
From: Sean.Engelson@cad.cs.cmu.edu
To: common-lisp@su-ai
Subject: Packages
Message-Id: <533853280/spe@cad.cs.cmu.edu>
This idea has probably been brought up before, but as a solution to the
'packages problem', without really any loos of functionality, I propose
the following: To have symbols be universal, but their values and
function definitions (maybe extended to all properties) be
package-tied. Thus symbols are symbols and are EQ to each other in all
the expectable cases, etc.., but we have the functionality of differing
name spaces. This could be implemented by having a PACKAGE 'property'
attached to different values of a symbol's property..
Pardon, but let me be the first to barf. Blech.
Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but
(eql 'FOO:QUUX 'BAR:QUUX) => T ??
First (to say it politely) I don't see how your solution solves
anything. Second, the more obvious solution of making
(EQL 'FOO:QUUX 'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable
in the presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL.
I don't think there's really a problem, and, if there is, I don't think
this solves it. (Sorry for the legal reasoning in that sentence).
-- Richard Soley
∂01-Dec-86 1350 spe@cad.cs.cmu.edu Re: Packages
Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 13:47:34 PST
Date: 1 Dec 1986 16:40-EST
From: Sean.Engelson@cad.cs.cmu.edu
To: Soley@MIT-XX.ARPA, common-lisp@su-ai
Subject: Re: Packages
Message-Id: <533857218/spe@cad.cs.cmu.edu>
Date: Mon, 1 Dec 86 16:25 EST
From: Soley@MIT-XX.ARPA
Subject: Packages
To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA
.......
Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql
'FOO:QUUX 'BAR:QUUX) => T ??
First (to say it politely) I don't see how your solution solves
anything. Second, the more obvious solution of making (EQL 'FOO:QUUX
'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable in the
presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL.
I guess my idea wasn't well-worded. Let me try to clarify. I would
remove any association of symbols to packages, thus there would be no
FU:QUUX, there would just be QUUX. However, QUUX's value and function
would be attached to packages, thus we could speak of QUUX's function
in package FU, or QUUX's value in package BAR. Thus we have separate
name spaces for functions and values, without the ridiculosity of
having to do interning, or string coercion whenever comparison of
symbols is needed.
-Sean Engelson-
∂01-Dec-86 1434 @MIT-LIVE-OAK.ARPA:Soley@MIT-XX.ARPA Re: Packages
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 14:32:56 PST
Received: from CHERRY.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 19849; Mon 1-Dec-86 17:31:31-EST
Date: Mon, 1 Dec 86 17:32 EST
From: Soley@MIT-XX.ARPA
Subject: Re: Packages
To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA
In-Reply-To: <533857218/spe@cad.cs.cmu.edu>
Message-ID: <861201173212.2.SOLEY@CHERRY.LCS.MIT.EDU>
Date: 1 Dec 1986 16:40-EST
From: Sean.Engelson@cad.cs.cmu.edu
Date: Mon, 1 Dec 86 16:25 EST
From: Soley@MIT-XX.ARPA
Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql
'FOO:QUUX 'BAR:QUUX) => T ??
I guess my idea wasn't well-worded. Let me try to clarify. I would
remove any association of symbols to packages, thus there would be no
FU:QUUX, there would just be QUUX. However, QUUX's value and function
would be attached to packages, thus we could speak of QUUX's function
in package FU, or QUUX's value in package BAR. Thus we have separate
name spaces for functions and values, without the ridiculosity of
having to do interning, or string coercion whenever comparison of
symbols is needed.
I don't see what this solves. You still need to /talk about/ functions
attached to symbols in other packages, in order to apply them. I was
just using "FOO:QUUX" as that syntax; are you suggesting something like
((function QUUX FOO) 1 2 3)
for the current (FOO:QUUX 1 2 3) ?? And if you want the A package value
of the symbol B, instead of A:B you have to type (value-of B 'A) or
something? That's just syntax. And there're separate
function/value/property slots for each symbol for each known package?
I think this makes the world more complex, not simpler. I think in most
cases you don't want the name of one of your symbols to be eq to another
symbol that just happens to have the same name, but is in another
package.
-- Richard Soley
∂01-Dec-86 1847 DALY@IBM.COM progv and dynamic variables
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 86 18:47:08 PST
Date: 1 December 1986, 13:53:21 EST
From: "Timothy P. Daly" <DALY@ibm.com>
To: common-lisp@su-ai.arpa
Message-Id: <120186.135322.daly@ibm.com>
Subject: progv and dynamic variables
What should the following do:
(defun foo (a s v)
(progv s v (print a)))
with:
(foo 3 '(a) '(4))
The actual result is 3 but from the book description of PROGV
on p112 it appears that it should be 4. I have tried this on
3 different common lisps with the same result.
∂01-Dec-86 1901 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU progv and dynamic variables
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 19:01:22 PST
Date: Mon, 1 Dec 1986 22:04 EST
Message-ID: <BROOKS.12259459812.BABYL@MIT-OZ>
From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: "Timothy P. Daly" <DALY@IBM.COM>
Cc: common-lisp@SU-AI.ARPA
Subject: progv and dynamic variables
In-reply-to: Msg of 1 Dec 1986 13:53:21 EST from Timothy P. Daly <DALY at ibm.com>
What should the following do:
(defun foo (a s v)
(progv s v (print a)))
with:
(foo 3 '(a) '(4))
The actual result is 3 but from the book description of PROGV
on p112 it appears that it should be 4. I have tried this on
3 different common lisps with the same result.
The `a' in (print a) refers to the lexical variable `a' named in
foo's parameter list. The progv binds the dynamic variable `a'.
You can get the answer to be 4 a number of ways:
1.
(defvar a)
(defun foo (a s v)
(progv s v (print a)))
This makes all references to `a' pervasively dynamic so even
the call to foo binds the dynamic `a'.
2.
(defun foo (a s v)
(declare (special a))
(progv s v (print a)))
Has the same effect on foo, but other functions can use a lexically
scoped `a'.
3.
(defun foo (a s v)
(progv s v
(declare (special a))
(print a)))
The binding of `a' during the call to foo is lexical, but the
reference in (print a) is dynamic.
∂01-Dec-86 1945 DLW@ALDERAAN.SCRC.Symbolics.COM progv and dynamic variables
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 1 Dec 86 19:45:44 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25355; Mon 1-Dec-86 22:43:50 EST
Date: Mon, 1 Dec 86 22:46 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: progv and dynamic variables
To: DALY%ibm.com@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <120186.135322.daly@ibm.com>
Message-ID: <861201224611.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Juse in case the sense of Rod's reply was not completely clear: the
answer is that it is supposed to be 3, not 4, so the implementations
were correct. PROGV always does a "special-bind" operation, regardless
of what's going on with declarations. The reference to "a" is a lexical
reference because there are no declarations making it a dynamic
reference.
∂01-Dec-86 2227 franz!ficl!jkf@ucbarpa.Berkeley.EDU Re: progv and dynamic variables
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 22:26:53 PST
Received: by ucbarpa.Berkeley.EDU (5.57/1.18)
id AA19366; Mon, 1 Dec 86 22:27:04 PST
Received: from ficl by franz (5.5/3.14)
id AA02598; Mon, 1 Dec 86 22:16:22 PST
Received: by ficl (5.5/3.14)
id AA27858; Mon, 1 Dec 86 22:17:00 PST
From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <ficl!jkf>
Message-Id: <8612020617.AA27858@ficl>
To: BROOKS%OZ.AI.MIT.EDU@xx.lcs.mit.edu
Cc: DALY@ibm.com, common-lisp@su-ai.arpa
Subject: Re: progv and dynamic variables
In-Reply-To: Your message of Mon, 01 Dec 86 22:04:00 EST.
<BROOKS.12259459812.BABYL@MIT-OZ>
Date: Mon, 01 Dec 86 22:16:58 PST
>> 3.
>> (defun foo (a s v)
>> (progv s v
>> (declare (special a))
>> (print a)))
>> The binding of `a' during the call to foo is lexical, but the
>> reference in (print a) is dynamic.
Aren't declarations illegal before a progv body?
-john foderaro
∂01-Dec-86 2250 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU progv and dynamic variables
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 22:47:24 PST
Date: Tue, 2 Dec 1986 01:50 EST
Message-ID: <BROOKS.12259501038.BABYL@MIT-OZ>
From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: franz!ficl!jkf@UCBARPA.BERKELEY.EDU (John Foderaro)
Cc: common-lisp@SU-AI.ARPA
Subject: progv and dynamic variables
In-reply-to: Msg of 2 Dec 1986 01:16-EST from franz!ficl!jkf at ucbarpa.Berkeley.EDU (John Foderaro)
Aren't declarations illegal before a progv body?
-john foderaro
Pages 153-154 seem to imply so. I guess the CL I have in front of
me has some extensions.
∂02-Dec-86 0928 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: Packages
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 2 Dec 86 09:28:41 PST
Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP
id aa00737; 2 Dec 86 17:07 WET
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Tue, 2 Dec 86 16:58:15 GMT
Message-Id: <21159.8612021658@aiva.ed.ac.uk>
To: Sean.Engelson@cad.cs.cmu.edu, Soley@xx.lcs.mit.edu, common-lisp@su-ai.arpa
Subject: Re: Packages
I believe Sean's suggestion is in intention equivalent to the proposal that
packages be replaced by something like Scheme's environments (T's locales).
That is, there would be only one symbol X, but it would have different
values in different environments. This is the sort of thing that happens
already, e.g. with closures. The difference is that these environments
would be separate data objects from which you can import values (rather
than their names), etc.
Several people have already expressed the opinion that the environment
approach is insufficiently developed to serve as a replacement for
packages. That may be so. In any case, packages and environemnts are more
or less independent since reference with respect to packages is resolved at
read time and with respect to environments at some eval-like time. So it
should be possible to experiment with environment-like approaches in
Common Lisp.
If anyone from the Scheme would like to explain how environments can be
implemented efficiently I'd be interested, but perhaps this list isn't the
best place to discuss it?
-- Jeff
∂02-Dec-86 1844 jbarnett@nrtc Packages then and now
Received: from NRTC.ARPA by SAIL.STANFORD.EDU with TCP; 2 Dec 86 18:43:46 PST
Date: Tue, 2 Dec 86 18:25:23 PST
From: Jeff Barnett <jbarnett@nrtc>
To: common-lisp@SU-AI.ARPA
Subject: Packages then and now
This note is in regargds to the recent conversation about packages. First, a
few historical comments. The first appearance in the LISP world was in LISP2
where global program pieces, e.g., special variables, functions, macros,
etc., where given a first and last name. (The first name was an integer in
the range of 0 to 127.) Symbols, then called identifiers, had only one
incarnation. LISP2 was done in the early 1960's. As far as I know, this
looked just like the mechansim used by IBM assemblers from the
early-middle 1950's. In both, there was a default package (first name) in
which to put definitions unless the name of the defined object included an
explicit package. Reference ambiguity was resolved, at compile time, by an
ordered list of package names. If a symbol (rather than a full name) was
used, if there was a definition in the first package on the list it was used;
if not, the second one was tried, and so on. For the record, packages were
called sections and the first name was really written second.
The last attempt at a development along these lines was an
implementation called CRISP done in the mid 1970's. In CRISP, symbols and
names were different kinds of objects: SYMBOLP and NAMEP were different
predicates and no object satisfied both. There were subtypes of name, e.g.,
variable, function, function with partially specified interface, etc. The
mechanism was to protect system developers from each other; not to protect
the system from the users. A name object had fields for its binding, type
information (as specifically as known), its print name (two symbols) and junk
for the GC. A symbol had fields for its printname, property list, and system
property list. The system property list located all name objects with this
primary name, i.e., all objects with this name in all the packages in which
it existed. The property list was tree structured. A node on the property
list was a 4-tuple: property name, property value, rest of property list,
and inferior property list. The property functions took a list of
indicators, e.g.,
(GET 'foo 'semantics 'lexicon 'phonetics)
Usually, the names of the first property was the same as a package name.
Most programs only used a single indicator while the layers below it used
two. Though the qualification string could be indefinately nested, more than
two indicators were rare. Further, the name qualification was only one deep
though it could have been generalized. It was not for two reasons: (1) it
didn't seem necessary and (2) the default rule became very complex. A
finally historical note, these systems were meant for Programmers (with a
capital P). They were not meant to separate the unwashed from each other.
In fact it is clear that, without change they cannot do the whole job.
As to the current state of affairs. I don't like the present package
system very much. I happen to like the distinction between symbols as
universals and names of program pieces. Unfortunately, in this
standardization effort, a change as radical as this would imply is probably
misguided. What I hope is that there will be a variety of implementations
that experiment with the issues that bridge naming, encapsulation, and
presentation. I don't know of an entirely satisfactory solution. Judging by
the recent flames, I see that no one else does either. The work on object
style programming in LISP will effect the future. Don't forget, that it is
another mechanism whose stated purpose is similar: namely to allow
development of different programs in the same environment AND development of
the same program by multiple contributors.
∂02-Dec-86 2113 Miller.pa@Xerox.COM Re: Packages then and now
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 86 21:13:46 PST
Received: from Salvador.ms by ArpaGateway.ms ; 02 DEC 86 20:54:20 PST
Date: 2 Dec 86 20:54 PST
Sender: Miller.pa@Xerox.COM
Subject: Re: Packages then and now
In-reply-to: Jeff Barnett <jbarnett@nrtc.ARPA>'s message of Tue, 2 Dec
86 18:25:23 PST
To: jbarnett@nrtc.ARPA
cc: common-lisp@SU-AI.ARPA
From: Mark S. Miller <Miller.pa@Xerox.COM>
Message-ID: <861202-205420-3471@Xerox>
Date: Tue, 2 Dec 86 18:25:23 PST
From: Jeff Barnett <jbarnett@nrtc.ARPA>
What I hope is that there will be a variety of implementations
that experiment with the issues that bridge naming, encapsulation,
and presentation. I don't know of an entirely satisfactory
solution. Judging by the recent flames, I see that no one else
does either.
What is non-satisfactory about T's scheme?
----- MarkM
∂02-Dec-86 2300 @REAGAN.AI.MIT.EDU:Henry@OZ.AI.MIT.EDU Common EVAL
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 86 22:59:29 PST
Received: from SINATRA.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 14027; Wed 3-Dec-86 01:58:41 EST
Date: Wed, 3 Dec 86 01:58 EST
From: CFry@OZ.AI.MIT.EDU
Sender: Henry@OZ.AI.MIT.EDU
Subject: Common EVAL
To: Common-Lisp@SU-AI.ARPA
cc: Henry@OZ.AI.MIT.EDU
Message-ID: <861203015844.2.HENRY@SINATRA.AI.MIT.EDU>
Reply-To: HENRY@AI.AI.MIT.EDU
Common EVAL
Henry Lieberman and Christopher Fry
Abstract
We propose that the Common Lisp standard be extended by adding to the
language specification a short program, itself written in Common Lisp, to
implement the EVAL function. The interpreters for every correct
implementation of Common Lisp would be required to match the semantics of
Common EVAL on valid Common Lisp expressions.
It should treat other expressions as errors or as implementation dependent
extensions. There are
three cogent reasons for including a Common EVAL in the standard:
First, since EVAL fixes the meaning of Lisp programs, it would
insure uniformity of program semantics across implementations.
Second, it would aid validation efforts, since the behavior of a
particular implementation could always be compared to the behavior
of Common EVAL. Third, it would facilitate the creation of debuggers
and other program-manipulating programs that could be ported across
Common Lisp implementations.
----------------------------------------------------------------------
One of the marvelous things about Lisp is that the language can be written in
itself. In Lisp, programs can be data and data can be programs. The
operation of the language itself can be described as a function written in
the very same language: the EVAL function. Lisp advocates always point
with pride to this fact as a major reason for Lisp's superiority over
conventional languages. It is why Lisp has traditionally supported the
best debugging environments. It is why Lisp can be used to write the
program-manipulating programs which are essential in artificial
intelligence work, and in building advanced interactive programming
environments.
Sadly, this important advantage is becoming steadily eroded by some of the
modern production implementations of Lisp. The quest for efficiency and
experimentation with esoteric programming constructs are leading to
non-standard implementations of Lisp interpreters that foil attempts
to make use of Lisp's self-descriptive capability.
With Common Lisp, we have a unique opportunity to insure that the
program-data equivalence which is one of Lisp's cornerstones remains
available as Lisp implementations proliferate. But the English
description in the Steele book is not detailed enough to exclude semantic
deviations which frustrate serious developers of program-manipulating
programs.
Specifying the EVAL function as a Common Lisp program can provide a
concise, precise, and easily understood description which could serve as a guide for
implementors and a means by which to evaluate the results.
Implementors would not be required to run the exact code for Common
EVAL in their implementation.
They could provide another implementation, which may be more efficient or include
extra features, but they would be required to assure that their version matched the
semantics of Common EVAL.
Differences in behavior between a particular Lisp implementation and Common EVAL
would be evidence for violations of the Common Lisp standard.
Many advanced Lisp applications rely on the precise details of the operation of
EVAL. Implementing a single-stepping debugger for Lisp code, for example,
requires imitating EVAL on Lisp expressions, while inserting display operations
and requesting input at events during evaluation.
Lisp's extensibility makes it ideal for defining embedded application-dependent
languages, which may even have a different control structure than Lisp's. Often,
these languages need to "use Lisp" as a subset, call Lisp functions from code in
the other language, or even invoke foreign language code from Lisp code. For
the interface to be smooth, the language designer must be able to depend on how
Lisp code is evaluated, perhaps including details such as variable environments
and function definitions.
Many programs which need to analyze Lisp programs statically require a "code
walker", a program that determines which subexpressions of a Lisp expression
represent code to be evaluated, and which represent data, like expressions which
appear inside a QUOTEd list. Such code walkers, which separate the uses of
Lisp expressions as programs from uses as data, appear in virtually every Lisp
compiler. Smart pretty-printers that print expressions according to their
semantics, indexers, or other "programmer's apprentice" tools need this, too.
Code walkers anticipate the action of EVAL on an expression, so they are
inextricably tied to EVAL's operation.
With Common EVAL, a designer of a program-manipulating program can base their
tools on the definition of Common EVAL rather than the details of a particular
Lisp implementation.
The implementor can then have confidence that the tools will work in all valid
implementations of Common Lisp.
This should significantly enhance Common Lisp's suitability for advanced applications.
The interpreters for MIT-descended Lisp Machines by Symbolics, LMI and TI
show how production implementations have compromised Lisp semantics.
Surprisingly, if you look at the system's definition of the EVAL
function, you will find that it only appears to be written in Lisp.
It calls "subprimitives" which are special-cased by the compiler, compiling
into specialized microcode, motivated by an attempt to make the Lisp interpreter more
efficient.
The subprimitives do things which, for example, violate the stack discipline of Lisp.
The system's definition of EVAL cannot even be interpreted by EVAL itself!
Because of the additional complexity that machine-dependent efficiency hacks add to
the evaluator, it is no longer feasible to write an EVAL without subprimitives, and
have any confidence that the results will be equivalent to the system's EVAL.
If the code for the evaluator relies on subprimitives, it won't even be intelligible to
the human reader literate only in Lisp.
This is not to say that we are against subprimitives; obviously, they are necessary
for such functions as CAR and EQ.
The English description of the behavior of lowest level functions in the
Steele book is adequate, as is the description of middle level functions like APPEND.
It is only when the complexity of something like EVAL is reached that
divergence among implementations becomes a real problem.
Periodically, internal changes to a system's evaluator require changing any
imitative implementation.
For example, Symbolics recently changed the function cell of an interpreted function
from containing a lambda expression to SI:DIGESTED-LAMBDA, which necessitated
similar changes in any program which expected to interpret functions.
A standard EVAL would clarify what representations a user could rely on, and clarify
what representations an implementor could change without breaking system code
or affecting users.
Another central problem is that "extensions" to the Lisp language may be
implemented in the interpreter by low-level constructs that cannot
be directly implemented by a Lisp program. While Common Lisp is
designed to permit extensions to the language, it should not allow
extensions which rely on microcode and other non-Lisp implementation techniques to
change the basic semantics of the language.
Such extensions effectively prevent any program-manipulating
program written in Common Lisp from operating on code containing
the extensions.
Spaghetti stacks in Interlisp are an example where an attempt to
implement non-standard programming constructs wreaks havoc with the
interpreter's semantics. It is impossible for an Interlisp
user to write a stepping debugger capable of working on interpreted code
that uses spaghetti stacks.
Common EVAL should provide well-defined points in the evaluation process at which
particular implementations could provide extensions, such as defining a new variety of
functional object.
How detailed should the Common EVAL implementation be? Everyone knows
that it is possible to implement a wide range of meta-circular
interpreters ranging from a one-page interpreter in the vein of the
original Lisp 1.5 book, to one that is so detailed it specifies every bit
and would probably run to hundreds of pages. Clearly, a middle course is
called for. The interpreter should be the minimal size necessary
to specify the interpreter in terms of calls to Common Lisp functions.
It should probably take no more than ten pages to do this. It should
be detailed enough to do things like specify the behavior of all
the special forms, but does not have to be so detailed as to
specify all the internal representations used by the evaluator.
The interpreter may need a variety of helping functions to access
representations of data structures, for example lexical variable binding
environments. To avoid constraining the freedom of implementors to choose
efficient representations for such data structures, Common EVAL could call
abstract functions whose implementation would not be prescribed by the
standard. Every implementation could provide its own EXTEND-ENVIRONMENT
function, whose behavior would be specified by a description, in the
manner of the Steele book. A simple Common Lisp implementation, for
example implementing environments as ALISTs, could be shown for
illustrative purposes without fixing the ALIST representation in every
Common Lisp implementation.
Finally, to illustrate the intent of our proposal more concretely, we present a
short segment of Lisp code for a skeleton Common EVAL. Don't take this code
too literally -- we mean it only to illustrate the style and the level of detail
we would expect of the real Common EVAL, and as a springboard for
discussion.
#|
Some notes about the code:
- The LE package contains the lexical environment manipulator
fns, many of which are yet to be written. If the CL community
decides to provide advertised support for lexical environment functions,
some of the functions here could be moved into to LISP package.
- The NOT-CL package contains miscellaneous support functions for Common EVAL.
- An implementation of eval is permitted to differ semantically
from Common EVAL only by redefining NOT-CL:EVAL.
This provides a well defined place for modifications to take place.
Our default definition here simply errors, as would a pure CL
implementation.
Functions here which are called, not in CL, and intended to be
defined by Common EVAL include:
- APPLY
- The lexical environment accessors.
- The functions for handling individual special forms.
- Closures and lexical functions are not dealt with yet.
|#
(defun eval (exp &optional lex-env)
"currently doesn't check for lex-env fns.
Right now, CL doesn't permit EVAL to take a 2nd arg.
LEX-ENV defaults to the null lexical environment."
(cond ((not-cl:self-evaluating-p exp) exp)
((symbolp exp) (not-cl:symbol-eval exp lex-env))
((consp exp)
(cond ((symbolp (car exp))
(cond ((macro-function (car exp))
(eval (macroexpand exp) lex-env))
((special-form-p (car exp))
(not-cl:eval-special-function-call exp lex-env))
((fboundp (car exp))
(apply (car exp)
(not-cl:list-of-values (cdr exp) lex-env)))
(t (not-cl:eval exp lex-env))))
((and (consp (car exp))
(eq (car (car exp)) 'lambda))
(apply (car exp) (cdr exp)))
(t (not-cl:eval exp lex-env))))
(t (not-cl:eval exp lex-env))))
(defun not-cl:self-evaluating-p (form)
(or (numberp form) (stringp form) (characterp form) (keywordp form)
(null form) (eq form t)))
(defun not-cl:symbol-eval (symbol lex-env)
"If SYMBOL is a variable in LEX-ENV, return its value.
Else If SYMBOL is bound, return its value,
else error."
(if (le:boundp symbol)
(le:symbol-value symbol lex-env)
(if (boundp symbol)
(symbol-value symbol)
(error "Attempt to evaluate an unbound symbol ~S" symbol))))
(defun not-cl:list-of-values (list lex-env)
(if list
(cons (eval (car list) lex-env)
(not-cl:list-of-values (cdr list) lex-env))))
(defun not-cl:eval-special-function-call (exp lex-env)
(case (car exp)
(block (not-cl:eval-block exp lex-env))
(catch (not-cl:eval-catch exp lex-env))
;...
(otherwise (error "not-cl:eval-special-function-call passed
non-implemented special form ~S" exp))))
(defun not-cl:eval (exp &optional lex-env)
(error "Eval passed non-CL form ~S" exp))
∂03-Dec-86 2318 hplb29a!hplbgw!weeks@hplabs.HP.COM Re: Packages
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 86 23:18:09 PST
Received: by hplabs.HP.COM ; Wed, 3 Dec 86 15:57:37 pst
Received: from hplbgw (hplbgw) by hplb29a ; Wed, 3 Dec 86 15:50:39 pst
Received: by hplbgw ; Wed, 3 Dec 86 15:50:22 pst
Date: Wed, 3 Dec 86 15:50:22 pst
From: Gregory Weeks <hplb29a!hplbgw!weeks@hplabs.HP.COM>
Message-Id: <8612032350.AA00381@hplbgw>
To: Soley@MIT-XX.ARPA, su-ai!common-lisp@hplabs.HP.COM,
hplabs!!cad.cs.cmu.edu!spe@SAIL.STANFORD.EDU
Subject: Re: Packages
.......
Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql
'FOO:QUUX 'BAR:QUUX) => T ??
First (to say it politely) I don't see how your solution solves
anything. Second, the more obvious solution of making (EQL 'FOO:QUUX
'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable in the
presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL.
I guess my idea wasn't well-worded. Let me try to clarify. I would
remove any association of symbols to packages, thus there would be no
FU:QUUX, there would just be QUUX. However, QUUX's value and function
would be attached to packages, thus we could speak of QUUX's function
in package FU, or QUUX's value in package BAR. Thus we have separate
name spaces for functions and values, without the ridiculosity of
having to do interning, or string coercion whenever comparison of
symbols is needed.
-Sean Engelson-
Hi. The notion you present is essentially the same as one I came up
with. Here is a summary of how I see it all working.
1. Symbols with the same name are identical. Symbols do not have
values, function-cells, package-cells, or property lists.
2. By definition, a BINDING associates a symbol and a "property"
(another symbol) with a value. A PACKAGE is a set of bindings.
At any given time, one package is current.
3. Defining constructs exist which create bindings and add them to the
current package. There are also referencing constructs which
access or mutate bindings. A binding may not be referenced before
it has been defined! (So bindings can not be created with SETF.)
(Names for defining constructs might be DEFVAR, DEFUN, DEFMACRO,
DEFTYPE, DEFSTRUCT, and so on, all of which would be special cases
of, say, DEFPROP.)
4. Constructs exist which allow a package to reference some of the
bindings of other packages. However, no two distinct bindings with
the same symbol and property may be referenceable (without
qualifiers) in any one package. Also, no package may redefine a
binding it did not define!
The above notion eliminates all spurious name clashes. It has several
drawbacks as far as Common Lisp is concerned. Here are the worst in
my opinion.
First, binding values are looked up (and possibly cached) as needed at
run time. I don't see how to do this efficiently. Second, Common Lisp
is already a standard, so major changes aren't reasonable. Finally,
while the above is the best I could come up with, I feel that there is
something else out there better. (For example, I don't know anything
about locales.)
Still, I think the idea you presented to be basically sound and
semantically a significant improvement over the status quo. Good
luck in getting Soley to see things the same way.
Greg Weeks
∂05-Dec-86 1604 RMA ANSI doings?
To: common-lisp@SAIL.STANFORD.EDU
Is anybody willing to post a precis of the current ANSI meetings?
∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU is it real or is it...
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:34:30 PST
Date: 5 Dec 1986 12:05-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: is it real or is it...
From: MATHIS@ADA20.ISI.EDU
To: common-lisp@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 12:05:20.MATHIS>
On page 56 of the November 1986 "High Technology Magazine" there
is an unidentified person in a picture. Is it Danny Bobrow or
some celebrity look-a-like that marketing found?
∂05-Dec-86 2055 shebs%utah-orion@utah-cs.arpa Underspecification of ~R
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 5 Dec 86 20:55:45 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA00374; Fri, 5 Dec 86 21:57:12 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA21384; Fri, 5 Dec 86 21:57:09 MST
Date: Fri, 5 Dec 86 21:57:09 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8612060457.AA21384@utah-orion.ARPA>
To: common-lisp@su-ai.arpa
Subject: Underspecification of ~R
In the description of the various : and @ options to ~R (cardinals, ordinals,
and two flavors of Roman numerals), it is said that any integer is printed
in the appropriate way. How should negative and very large integers be
handled? HP CL prints out a "negative " for negative cardinals and ordinals,
and prints out various error messages for other cases. I would prefer to
see "minus four" and have an error for negative cardinals, since "minus
fourth" sounds pretty strange! Sandra suggests "a lot" as the right way
to print large integers, while I favor "many" (consider the New Guinea
tribes whose number system is "one", "two", "three", "many"). There should
also be a definite bound on integer size (I would make it low; "five
decillion" also looks pretty strange). Finally, keep in mind that Americans
and Britons do things differently above one million - perhaps the time
zone returned by get-decoded-time should be used to decide whether to
print "billion" or "milliard" (which do Canadians use anyway?).
Of course, the : and @ options could just be omitted...
stan the obscure
∂06-Dec-86 0758 MATHIS@ADA20.ISI.EDU ANSI doings
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 6 Dec 86 07:57:58 PST
Date: 6 Dec 1986 07:29-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: ANSI doings
From: MATHIS@ADA20.ISI.EDU
To: common-lisp@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 6-Dec-86 07:29:54.MATHIS>
The next X3J13 meeting will be in Dallas, TX, Dec 10-12, 1986.
Topics on the agenda include the function cell value cell issue
and a discussion of error systems. The first meeting included a
discussion of object system proposals and "minor" corrections to
the Steele book.
There is a separate mailing list for X3J13. If you are
interested, please reply directly to me.
We are also beginning to discuss how to take advantage of the
open technical interchange which occurs here and then work that
into X3J13 decision making about the eventual standard. Thoughts
on this topic may be communicated directly to me or to the whole
common-lisp mailing list. When a suggestion on how to do this is
put together, I will be sure that it is circulated to the whole
community (not just X3J13).
-- Bob Mathis, Convenor and Acting Chairman, X3J13
∂07-Dec-86 2249 ELIOT%cs.umass.edu@RELAY.CS.NET Added Keyword argument to load.
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Dec 86 22:48:53 PST
Received: from cs.umass.edu by csnet-relay.csnet id aq13844; 8 Dec 86 1:32 EST
Date: Sun, 7 Dec 86 18:11 EDT
From: ELIOT%cs.umass.edu@RELAY.CS.NET
To: Common-lisp@SU-AI.ARPA
Subject: Added Keyword argument to load.
X-VMS-To: CSNET%"Common-lisp@su-ai.arpa"
I would find a "compile" option for the LOAD function to be quite
useful. It would be a simple, upwards compatible change to add
a :COMPILE keyword argument whose values would be NIL (default), T
or :IF-NEEDED. NIL and T would mean never and always. :IF-NEEDED would
specify that LOAD should check the FILE-WRITE-DATE of the source
and (possibly non-existent) previous binary file, and compile the source
if the binary doesn't exist or is older than the source.
This would not be intended to replace a full fledged source code control
system or system rebuilder like the Lisp Machine supplies. It would
be very useful for people, (like students) who write many small Lisp
programs. Each semester I write several programs, none of which normally
have more than five source files, and no complicated dependancies.
However, I may be forced to move among many different machines,
and it may be impossible for me to maintain a single library of
"personal" utilities that can be accessed by all of the machines I use.
With these needs in mind the two semantic issues of my proposal can
be dealt with.
(1) What should be done about compile-time/load-time dependancies.
For example should there be any concern about loading macro libraries
before compiling specific files.
Answer: No. Those issues should be dealt with by a larger scale,
probably implementation dependant utility. These issues are not
critical for small (< 2000 lines) programs which is the scal of programs
which this feature attempts to support.
(2) How can LOAD determine which source file corresponds to which compiled
file.
Answer: (1) Load already is defined to know how to do this, because
it can "in some implementation dependant way" choose whether to
load a text or object version of the file.
(2) It should check at least the files which it would otherwise
load, and it should check the files which COMPILE-FILE would read and
write if COMPILE-FILE were given the same argument.
Implementations which don't distinguish compiled files would obviously
be free to ignore this keyword.
∂08-Dec-86 0531 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Underspecification of ~R
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 8 Dec 86 05:31:33 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34474; Mon 8-Dec-86 08:29:36 EST
Date: Mon, 8 Dec 86 08:29 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Underspecification of ~R
To: Stanley T. Shebs <shebs%utah-orion@UTAH-CS.ARPA>,
common-lisp@SU-AI.ARPA
In-Reply-To: <8612060457.AA21384@utah-orion.ARPA>
Message-ID: <861208082926.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Fri, 5 Dec 86 21:57:09 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
... I would prefer to see "minus four" and have an error for
negative cardinals, since "minus fourth" sounds pretty strange!
(dolist (power '(-4 -2 0 2 4))
(format t "~A to the ~:R power~%" "X" power))
X to the minus fourth power
X to the minus second power
X to the zeroth power
X to the second power
X to the fourth power
Doesn't sound strange to me.
Sandra suggests "a lot" as the right way
to print large integers, while I favor "many" (consider the New Guinea
tribes whose number system is "one", "two", "three", "many"). There should
also be a definite bound on integer size (I would make it low; "five
decillion" also looks pretty strange). Finally, keep in mind that Americans
and Britons do things differently above one million - perhaps the time
zone returned by get-decoded-time should be used to decide whether to
print "billion" or "milliard" (which do Canadians use anyway?).
Security in obscurity? Some systems (e.g. Symbolics) punt after certain
limits.
(dotimes (i 10)
(format t "10↑~D ~@R~%" i (expt 10 i)))10↑0 I
10↑1 X
10↑2 C
10↑3 M
10↑4 10000
10↑5 100000
10↑6 1000000
10↑7 10000000
10↑8 100000000
10↑9 1000000000
(do ((i 8 (+ i 2))) ((> i 50))
(format t "10↑~D ~R~%" i (expt 10 i)))
10↑8 one hundred million
10↑10 ten billion
10↑12 one trillion
10↑14 one hundred trillion
10↑16 ten quadrillion
10↑18 one quintillion
10↑20 one hundred quintillion
10↑22 ten sextillion
10↑24 one septillion
10↑26 one hundred septillion
10↑28 ten octillion
10↑30 one nonillion
10↑32 one hundred nonillion
10↑34 ten decillion
10↑36 one undecillion
10↑38 one hundred undecillion
10↑40 ten duodecillion
10↑42 one times ten to the forty-second power
10↑44 one hundred times ten to the forty-second power
10↑46 ten times ten to the forty-fifth power
10↑48 one times ten to the forty-eighth power
10↑50 one hundred times ten to the forty-eighth power
One could possibly claim no "reasonable" program would be working
properly (or was given proper inputs) if it ever tried to make such
large numbers intelligible.
Of course, the : and @ options could just be omitted...
stan the obscure
∂08-Dec-86 1256 @DIAMOND.S4CC.Symbolics.COM:chaowatkins@STONY-BROOK.SCRC.Symbolics.COM X3J13 mailing list
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 8 Dec 86 12:56:21 PST
Received: from PENG.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34724; Mon 8-Dec-86 15:53:43 EST
Date: Mon, 8 Dec 86 15:53 EST
From: susan watkins <chaowatkins@STONY-BROOK.SCRC.Symbolics.COM>
Subject: X3J13 mailing list
To: MATHIS@ADA20.ISI.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <[ADA20.ISI.EDU] 6-Dec-86 07:29:54.MATHIS>
Message-ID: <861208155333.5.CHAOWATKINS@PENG.S4CC.Symbolics.COM>
Date: 6 Dec 1986 07:29-PST
From: MATHIS@ADA20.ISI.EDU
The next X3J13 meeting will be in Dallas, TX, Dec 10-12, 1986.
Topics on the agenda include the function cell value cell issue
and a discussion of error systems. The first meeting included a
discussion of object system proposals and "minor" corrections to
the Steele book.
There is a separate mailing list for X3J13. If you are
interested, please reply directly to me.
Please put me on the mailing list. Thanks.
My arpa address is :
chaowatkins@srcr-stony-brook.arpa
[..... ]
-- Bob Mathis, Convenor and Acting Chairman, X3J13
∂08-Dec-86 2233 RPG Re: testing suite
p8-Dec-86 1243 berman@vaxa.isi.edu Re: testing suite
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 86 12:39:54 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA09635; Mon, 8 Dec 86 12:38:46 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8612082038.AA09635@vaxa.isi.edu>
Date: 8 Dec 1986 1238-PST (Monday)
To: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet%RELAY.CS.NET@vaxa.isi.edu>
Cc: berman@VAXA.ISI.EDU, fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
ida%u-tokyo.junet%RELAY.CS.NET@vaxa.isi.edu, mathis@ADA20.ISI.EDU,
ohlandar@VAXA.ISI.EDU, rpg@SU-AI.ARPA
Subject: Re: testing suite
In-Reply-To: Your message of Wed, 26 Nov 86 17:18:19+0900.
<8611260818.AA03707@ccut.u-tokyo.junet>
Here is the explanation I promised. It is sort of rough, but...
------------------------------------------------------------------
DEFTEST is used to define a test. It puts the test into a database.
The arguments are:
ITEM which is one of the common lisp function names, variables, macro names,
etc. or a subject name. The name must be present in the organizing
database.
NAME must be a unique symbol for this test. If not provided, a unique name
is created.
TYPE is optional, defaulting to :NOEVAL. It must be one of :NOEVAL,
:EVAL or :ERROR. :NOEVAL means the testform eval section is
evaluated and compared (using the indicated compare in the testform)
with the unevaluated compare section. :EVAL means both halves
are evaluated and compared. :ERROR means the form should produce
an error.
TESTFORM is the test form, composed of 1 or 3 parts. If this is
and :ERROR test, TESTFORM is an expresion which must produce
an error. Otherwise there are 3 parts. The first is a form
which can be used as a function by APPLY, taking two arguments
and used to compare the results of the eval and compare forms.
The second form is the eval form, which is evaluated.
The compare form is either evalutated (type :EVAL) or not
(type :NOEVAL).
The remaining arguments are optional, referenced by keywords. They are:
:CONTRIB$ is a documentation string showing the originator of the test.
If unspecified or NIL it gets its value from CL-TESTS:*CONTRIB$*
:FAILFORM is a form to evaluate in the event that an unexpected error
was generated, or the comparison failed.
:ERROR$ is a string to print out if the comparison fails.
:SETUP is a form to evaluate before TESTFORM.
:UNSETUP is a form to evaluate after TESTFORM.
:DOC$ is a string documenting this test. If not specified (or nil) it
gets it value from the global variable CL-TESTS:*DOC$*
:CONTROL may be any of :GLOBAL, :EVAL-ONLY or :COMPILE-ONLY. If it is :GLOBAL,
it means that the test controller will decide when/if to eval and
compile the test. If it is :EVAL, then the test will ignore
controller attempts to compile it, and if it is :COMPILE the
controller cannot eval it. The default is :GLOBAL.
(defmacro DEFTEST
((item &optional (name :not-provided) (type ':noeval))
testform
&key (contrib$ *contrib$*)
(failform nil)
(error$ nil)
(setup nil)
(unsetup nil)
(doc$ nil)
(control :GLOBAL)) ...)
Here a an example useage:
(deftest
(aref)
(EQUAL (AREF (MAKE-ARRAY 5 :INITIAL-CONTENTS '(1 2 3 4 5)) 3)
4)
:doc$ "array - 1 dimensional array of 5 elements, subscript 3")
This shows a simple use with NAME and TYPE not provided, as well
as most of the &KEY arguments. Only :DOC$ is specified. Here is
a more involved example:
(deftest
(block)
(eq (aux) t)
:setup (defun aux () (return-from aux t))
:unsetup (fmakunbound 'aux)
:doc$ "DEFUN implicitly defines a BLOCK")
This uses the :SETUP and :UNSETUP keywords. Some keyword arguments
are rarely used. :FAILFORM is currently unused, being reserved
for future application.
Often a whole series of tests have the same CONTRIB$ and/or
DOC$. The global variables *CONTRIB$* and *DOC$* are used
to simplify this use, as follows:
(setq *contrib$* "contributor string")
(setq *doc$* "documentation string")
(deftest ...)
(deftest ...)
(setq *contrib$* nil *doc$* nil)
If any of the deftest forms have a :CONTRIB$ or :DOC$ keyword
used, that would override the defaults set in the global
variables, but only for that deftest form.
The :ERROR$ parameter is somewhat experimental just now. I don't
recommend using it, but currently, when an error occurs while
running a test, if there is a given :ERROR$, then a statement like
(format *test-error-stream* error$ name (car evalform) nil result contrib$)
is executed, where *TEST-ERROR-STREAM* is the run-time error
reporting stream (usually just T), ERROR$ is the given string,
NAME is the test name, (CAR EVALFORM) is the first form (the
one always evaluated), RESULT is the result of executing
(CAR EVALFORM), and CONTRIB$ contains the name of the author.
For example:
(deftest
(+ +-int-13)
(eq (+ -7 5) -3)
:error$ "~s failed. (eq ~s ~s).~%")
would cause "+-INT-13 failed. (eq -2 -3)." to be printed (of
course, without the enclosing quote marks).
If the test type is :ERROR, then the format string for :ERROR$ is
used like this:
(format *test-error-stream* error$ name (car evalform) contrib$)
with the same meanings.
TEST SEQUENCES
Because the tests are all put into a data base, the ordering of
the tests (from the input file) is normally lost. Usually each
test is independent of another. However, at times you have
an extensive environment around a group of tests (using :SETUP
and :UNSETUP) that is inconvenient to duplicate for each
test. And also sometimes the exact order of tests IS important.
In this case, you would use DEFTEST-SEQ to define a sequence of
tests.
(defmacro DEFTEST-SEQ ((item seq-name)
test-seq
&key (contrib$ *contrib$*)
(setup nil)
(unsetup nil)
(doc$ *doc$*)) ...)
This uses an ITEM as in DEFTEST, and adds the concept of the
SEQ-NAME. This is a unique name assigned to the entire
sequence of tests.
TEST-SEQ is the list of tests, formatted like so:
(( NIL | (<test name> <optional type>)
testform
<optional keyword data>)
( NIL | (<test name> <optional type>)
testform
<optional keyword data>)
...)
This is a list of forms. Each form has a CAR that is
either NIL or a list containing at least the name of this
testform, and, optionally, the test type as in DEFTEST.
If no name is given (because we used NIL instead of a list
here) then the name is constructed from the SEQ-NAME.
The TESTFORM is a form as in DEFTEST, varying in structure
depending on if TYPE is :ERROR or not. The optional
keyword data is exactly as per DEFTEST.
Here is an example:
(deftest-seq
(apply apply-CDC-tests)
(
(nil
(eq (APPLY #'+ '()) 0))
(nil
(equal (APPLY #'(LAMBDA (&KEY A B) (LIST A B)) '(:B 3))
(nil 3))
:doc$ "Book test, page 108")))
This shows a sequence of APPLY, named APPLY-CDC-TESTS. It
has two tests in it, each automatically named and defaulting
to NOEVAL type. The second test has a :DOC$ value.
In addition to the keywords that may appear on each test, the
entire sequence may have the keywords :CONTRIB$, :SETUP,
:UNSETUP and :DOC$. These act as defaults for each individual
test in the sequence, being overridden by any use of these
keywords in the individual test.
Typically a sequence would have an environment specified by
:SETUP and :UNSETUP which would be used by the tests in the
sequence.
Here are some actual samples of tests. These were converted
from tests supplied by CDC. I make no guarantee of their
usefullness or correctness, except as examples of the
test format.
----------------------------------------------------------
;; -*- mode:Common-Lisp; Base: 10; Package:cl-tests -*-
(in-package 'cl-tests)
(setq *contrib$* "CDC")
(setq *DOC$* "Test Integer Addition.")
(deftest
(+ +-int-1)
(eq (+ 1 2) 3))
(deftest
(+ +-int-2)
(eq (+ 0 0) 0))
(deftest
(+ +-int-3)
(eq (+) 0))
(deftest
(+ +-int-4)
(eq (+ 1 2 3 4 5 6 7 8 9 10) 55))
(deftest
(+ +-int-5)
(eq (+ -5) -5))
(deftest
(+ +-int-6)
(eq (+ 10) 10))
(deftest
(+ +-int-7)
(eq (+ 1 (+ 1 1)) 3))
(deftest
(+ +-int-8)
(eq (+ 5 (+ 7 -7)) 5))
(deftest
(+ +-int-9)
(eq (+ 4 (+ 3 (+ 2 (+ 1)))) 10))
(deftest
(+ +-int-11)
(eq (+ 1514 (- 1511)) 3))
(deftest
(+ +-int-12)
(eq (+ 0) 0))
(deftest
(+ +-int-13)
(eq (+ -7 5) -2))
(deftest
(+ +-int-14)
(eq (+ 1 -2 +3 -4 5 -6 +7 -8 9 -10) -5))
(deftest
(+ +-int-15)
(eq (+ 1793 22485) 24278))
(deftest-seq
(+ CDC-+-FLOAT-TESTS)
((nil
(ADD-P (+ 0.01 0.1) 0.11))
(nil
(add-p (+ 0.0) 0.0))
(nil
(add-p (+ 0.0 0.000) 0))
(nil
(add-p (+ 0.0 0.12) 0.12))
(nil
(add-p (+ 1.23 0) 1.23))
(nil
(add-p (+ 2.401E125 5.738E123) 2.45838E125))
(nil
(add-p (+ 0.1 0.11 0.111 0.1111) 0.4321))
(nil
(add-p (+ 0.1 -1.01 +10.001 -100.0001 1000.00001) 909.09091))
(nil
(add-p (+ 12.4 2.31 (+ 10.38 25.77)) 50.86))
(nil
(add-p (+ 0.001) 0.001))
(nil
(add-p (+ 0.1 (+ 0.11 (+ 0.111 (+ 0.1111 0.11111)))) 0.54321))
(nil
(add-p (+ A B) 55.761)))
:setup (progn
(DEFUN ABSOLUTE_V (G1 G2)
(IF (MINUSP (- G1 G2)) (- G2 G1) (- G1 G2)))
(DEFUN ADD-P (G1 G2)
(COND ((EQUAL G1 G2) T)
((< (/ (ABSOLUTE_V G1 G2)
G1) 1E-10) T)))
(SETQ A (+ 50.481 (SET 'B (+ 2.41 0.23)))))
:unsetup (progn
(makunbound 'a)
(makunbound 'b)
(fmakunbound 'add-p)
(fmakunbound 'absolute_v))
:doc$ "Floating point test of +. Not sure that the values are meaningful in the ADD function here!")
(deftest-seq
(+ +-float/int-tests)
((nil
(add-p (+ 0 0.0 -0.0 +0. -0) 0))
(nil
(add-p (+ 50.3 41 -24 -18.73) 48.57))
(nil
(add-p (+ 5 4.4 3 (+ 2.2 1 0.1) -2.7 -4 -4.5) 4.5))
(nil
(add-p (+ 54321.12345 54321 2.7E3 -9.99E+06) -9878657.87655))
(nil
(add-p (+ 5.4879993E-3 -1005.4879992E-3 1) 9.9994679203E-11))
(nil
(add-p (+ 8.76E122 9.766E-3 6543210) 8.76E122))
(nil
(add-p (+ 1 3 5 (+) (+ 6) (+ 1.1 3.3 5.5 (+) (+ 6.6)) 8) 39.5))
(nil
(add-p (+ 300 20 1 0 .1 .02 .003 .0004 .00005 .000006 (-(+ 321 0.123456))) -7.27595E-12)))
:doc$ "test the ADD function under the floating point and integer calculation"
:setup (DEFUN ADD-p (G1 G2)
(PROG (ADD_V)
(SETQ ADD_V (- G1 G2))
(COND ((OR (AND (< 0 G1)
(< 0 ADD_V))
(AND (< G1 0)
(< ADD_V 0)))
T))
(COND ((< (/ ADD_V G1) 1E-5) (RETURN T))
(T (RETURN NIL)))))
:unsetup (fmakunbound 'add-p))
------------------------------------------------------------
;; -*- Mode:Common-Lisp; Base: 10; Package:cl-tests -*-
(in-package 'cl-tests #m :use #m "lisp")
(setq *contrib$* "Pete Warburton @ CDC")
(setq *doc$* nil)
(deftest-seq
(boole boole-CDC)
((nil
(eq (boole boole-clr logtest01 logtest10) 0))
(nil
(eq (boole boole-set logtest01 logtest10) -1))
(nil
(eq (boole boole-1 logtest01 logtest10) logtest01))
(nil
(eq (boole boole-2 logtest01 logtest10) logtest10))
(nil
(eq (boole boole-c1 logtest01 logtest10) (lognot logtest01)))
(nil
(eq (boole boole-c2 logtest01 logtest10) (lognot logtest10)))
(nil
(eq (boole boole-and logtest01 logtest10) logtest0))
(nil
(eq (boole boole-ior logtest01 logtest10) logtest1))
(nil
(eq (boole boole-xor logtest01 logtest10) logtest1))
(nil
(eq (boole boole-eqv logtest01 logtest10) (lognot logtest1)))
(nil
(equal (boole boole-nand logtest01 logtest10) (lognot logtest0)))
(nil
(equal (boole boole-nor logtest01 logtest10) (lognot logtest1)))
(nil
(equal (boole boole-andc1 logtest01 logtest10) logtest10))
(nil
(equal (boole boole-andc2 logtest01 logtest10) logtest01))
(nil
(equal (boole boole-orc1 logtest01 logtest10) (lognot logtest01)))
(nil
(equal (boole boole-orc2 logtest01 logtest10) (lognot logtest10))))
:setup (progn
(setq logtest0 0)
(setq logtest-1 -1)
(setq logtest1 (+ 1 2 4 8 16 32 64 128 256 512 1024 2048 ))
(setq logtest01 (+ 1 4 16 64 256 1024))
(setq logtest10 (+ 2 8 32 128 512 2048 )))
:unsetup (progn
(makunbound logtest9)
(makunbound logtest-1)
(makunbound logtest1)
(makunbound logtest01)
(makunbound logtest10)))
----------------------------------------------------------
RB
∂08-Dec-86 2237 RPG Common EVAL
∂02-Dec-86 2300 @REAGAN.AI.MIT.EDU:Henry@OZ.AI.MIT.EDU Common EVAL
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 86 22:59:29 PST
Received: from SINATRA.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 14027; Wed 3-Dec-86 01:58:41 EST
Date: Wed, 3 Dec 86 01:58 EST
From: CFry@OZ.AI.MIT.EDU
Sender: Henry@OZ.AI.MIT.EDU
Subject: Common EVAL
To: Common-Lisp@SU-AI.ARPA
cc: Henry@OZ.AI.MIT.EDU
Message-ID: <861203015844.2.HENRY@SINATRA.AI.MIT.EDU>
Reply-To: HENRY@AI.AI.MIT.EDU
Common EVAL
Henry Lieberman and Christopher Fry
Abstract
We propose that the Common Lisp standard be extended by adding to the
language specification a short program, itself written in Common Lisp, to
implement the EVAL function. The interpreters for every correct
implementation of Common Lisp would be required to match the semantics of
Common EVAL on valid Common Lisp expressions.
It should treat other expressions as errors or as implementation dependent
extensions. There are
three cogent reasons for including a Common EVAL in the standard:
First, since EVAL fixes the meaning of Lisp programs, it would
insure uniformity of program semantics across implementations.
Second, it would aid validation efforts, since the behavior of a
particular implementation could always be compared to the behavior
of Common EVAL. Third, it would facilitate the creation of debuggers
and other program-manipulating programs that could be ported across
Common Lisp implementations.
----------------------------------------------------------------------
One of the marvelous things about Lisp is that the language can be written in
itself. In Lisp, programs can be data and data can be programs. The
operation of the language itself can be described as a function written in
the very same language: the EVAL function. Lisp advocates always point
with pride to this fact as a major reason for Lisp's superiority over
conventional languages. It is why Lisp has traditionally supported the
best debugging environments. It is why Lisp can be used to write the
program-manipulating programs which are essential in artificial
intelligence work, and in building advanced interactive programming
environments.
Sadly, this important advantage is becoming steadily eroded by some of the
modern production implementations of Lisp. The quest for efficiency and
experimentation with esoteric programming constructs are leading to
non-standard implementations of Lisp interpreters that foil attempts
to make use of Lisp's self-descriptive capability.
With Common Lisp, we have a unique opportunity to insure that the
program-data equivalence which is one of Lisp's cornerstones remains
available as Lisp implementations proliferate. But the English
description in the Steele book is not detailed enough to exclude semantic
deviations which frustrate serious developers of program-manipulating
programs.
Specifying the EVAL function as a Common Lisp program can provide a
concise, precise, and easily understood description which could serve as a guide for
implementors and a means by which to evaluate the results.
Implementors would not be required to run the exact code for Common
EVAL in their implementation.
They could provide another implementation, which may be more efficient or include
extra features, but they would be required to assure that their version matched the
semantics of Common EVAL.
Differences in behavior between a particular Lisp implementation and Common EVAL
would be evidence for violations of the Common Lisp standard.
Many advanced Lisp applications rely on the precise details of the operation of
EVAL. Implementing a single-stepping debugger for Lisp code, for example,
requires imitating EVAL on Lisp expressions, while inserting display operations
and requesting input at events during evaluation.
Lisp's extensibility makes it ideal for defining embedded application-dependent
languages, which may even have a different control structure than Lisp's. Often,
these languages need to "use Lisp" as a subset, call Lisp functions from code in
the other language, or even invoke foreign language code from Lisp code. For
the interface to be smooth, the language designer must be able to depend on how
Lisp code is evaluated, perhaps including details such as variable environments
and function definitions.
Many programs which need to analyze Lisp programs statically require a "code
walker", a program that determines which subexpressions of a Lisp expression
represent code to be evaluated, and which represent data, like expressions which
appear inside a QUOTEd list. Such code walkers, which separate the uses of
Lisp expressions as programs from uses as data, appear in virtually every Lisp
compiler. Smart pretty-printers that print expressions according to their
semantics, indexers, or other "programmer's apprentice" tools need this, too.
Code walkers anticipate the action of EVAL on an expression, so they are
inextricably tied to EVAL's operation.
With Common EVAL, a designer of a program-manipulating program can base their
tools on the definition of Common EVAL rather than the details of a particular
Lisp implementation.
The implementor can then have confidence that the tools will work in all valid
implementations of Common Lisp.
This should significantly enhance Common Lisp's suitability for advanced applications.
The interpreters for MIT-descended Lisp Machines by Symbolics, LMI and TI
show how production implementations have compromised Lisp semantics.
Surprisingly, if you look at the system's definition of the EVAL
function, you will find that it only appears to be written in Lisp.
It calls "subprimitives" which are special-cased by the compiler, compiling
into specialized microcode, motivated by an attempt to make the Lisp interpreter more
efficient.
The subprimitives do things which, for example, violate the stack discipline of Lisp.
The system's definition of EVAL cannot even be interpreted by EVAL itself!
Because of the additional complexity that machine-dependent efficiency hacks add to
the evaluator, it is no longer feasible to write an EVAL without subprimitives, and
have any confidence that the results will be equivalent to the system's EVAL.
If the code for the evaluator relies on subprimitives, it won't even be intelligible to
the human reader literate only in Lisp.
This is not to say that we are against subprimitives; obviously, they are necessary
for such functions as CAR and EQ.
The English description of the behavior of lowest level functions in the
Steele book is adequate, as is the description of middle level functions like APPEND.
It is only when the complexity of something like EVAL is reached that
divergence among implementations becomes a real problem.
Periodically, internal changes to a system's evaluator require changing any
imitative implementation.
For example, Symbolics recently changed the function cell of an interpreted function
from containing a lambda expression to SI:DIGESTED-LAMBDA, which necessitated
similar changes in any program which expected to interpret functions.
A standard EVAL would clarify what representations a user could rely on, and clarify
what representations an implementor could change without breaking system code
or affecting users.
Another central problem is that "extensions" to the Lisp language may be
implemented in the interpreter by low-level constructs that cannot
be directly implemented by a Lisp program. While Common Lisp is
designed to permit extensions to the language, it should not allow
extensions which rely on microcode and other non-Lisp implementation techniques to
change the basic semantics of the language.
Such extensions effectively prevent any program-manipulating
program written in Common Lisp from operating on code containing
the extensions.
Spaghetti stacks in Interlisp are an example where an attempt to
implement non-standard programming constructs wreaks havoc with the
interpreter's semantics. It is impossible for an Interlisp
user to write a stepping debugger capable of working on interpreted code
that uses spaghetti stacks.
Common EVAL should provide well-defined points in the evaluation process at which
particular implementations could provide extensions, such as defining a new variety of
functional object.
How detailed should the Common EVAL implementation be? Everyone knows
that it is possible to implement a wide range of meta-circular
interpreters ranging from a one-page interpreter in the vein of the
original Lisp 1.5 book, to one that is so detailed it specifies every bit
and would probably run to hundreds of pages. Clearly, a middle course is
called for. The interpreter should be the minimal size necessary
to specify the interpreter in terms of calls to Common Lisp functions.
It should probably take no more than ten pages to do this. It should
be detailed enough to do things like specify the behavior of all
the special forms, but does not have to be so detailed as to
specify all the internal representations used by the evaluator.
The interpreter may need a variety of helping functions to access
representations of data structures, for example lexical variable binding
environments. To avoid constraining the freedom of implementors to choose
efficient representations for such data structures, Common EVAL could call
abstract functions whose implementation would not be prescribed by the
standard. Every implementation could provide its own EXTEND-ENVIRONMENT
function, whose behavior would be specified by a description, in the
manner of the Steele book. A simple Common Lisp implementation, for
example implementing environments as ALISTs, could be shown for
illustrative purposes without fixing the ALIST representation in every
Common Lisp implementation.
Finally, to illustrate the intent of our proposal more concretely, we present a
short segment of Lisp code for a skeleton Common EVAL. Don't take this code
too literally -- we mean it only to illustrate the style and the level of detail
we would expect of the real Common EVAL, and as a springboard for
discussion.
#|
Some notes about the code:
- The LE package contains the lexical environment manipulator
fns, many of which are yet to be written. If the CL community
decides to provide advertised support for lexical environment functions,
some of the functions here could be moved into to LISP package.
- The NOT-CL package contains miscellaneous support functions for Common EVAL.
- An implementation of eval is permitted to differ semantically
from Common EVAL only by redefining NOT-CL:EVAL.
This provides a well defined place for modifications to take place.
Our default definition here simply errors, as would a pure CL
implementation.
Functions here which are called, not in CL, and intended to be
defined by Common EVAL include:
- APPLY
- The lexical environment accessors.
- The functions for handling individual special forms.
- Closures and lexical functions are not dealt with yet.
|#
(defun eval (exp &optional lex-env)
"currently doesn't check for lex-env fns.
Right now, CL doesn't permit EVAL to take a 2nd arg.
LEX-ENV defaults to the null lexical environment."
(cond ((not-cl:self-evaluating-p exp) exp)
((symbolp exp) (not-cl:symbol-eval exp lex-env))
((consp exp)
(cond ((symbolp (car exp))
(cond ((macro-function (car exp))
(eval (macroexpand exp) lex-env))
((special-form-p (car exp))
(not-cl:eval-special-function-call exp lex-env))
((fboundp (car exp))
(apply (car exp)
(not-cl:list-of-values (cdr exp) lex-env)))
(t (not-cl:eval exp lex-env))))
((and (consp (car exp))
(eq (car (car exp)) 'lambda))
(apply (car exp) (cdr exp)))
(t (not-cl:eval exp lex-env))))
(t (not-cl:eval exp lex-env))))
(defun not-cl:self-evaluating-p (form)
(or (numberp form) (stringp form) (characterp form) (keywordp form)
(null form) (eq form t)))
(defun not-cl:symbol-eval (symbol lex-env)
"If SYMBOL is a variable in LEX-ENV, return its value.
Else If SYMBOL is bound, return its value,
else error."
(if (le:boundp symbol)
(le:symbol-value symbol lex-env)
(if (boundp symbol)
(symbol-value symbol)
(error "Attempt to evaluate an unbound symbol ~S" symbol))))
(defun not-cl:list-of-values (list lex-env)
(if list
(cons (eval (car list) lex-env)
(not-cl:list-of-values (cdr list) lex-env))))
(defun not-cl:eval-special-function-call (exp lex-env)
(case (car exp)
(block (not-cl:eval-block exp lex-env))
(catch (not-cl:eval-catch exp lex-env))
;...
(otherwise (error "not-cl:eval-special-function-call passed
non-implemented special form ~S" exp))))
(defun not-cl:eval (exp &optional lex-env)
(error "Eval passed non-CL form ~S" exp))
∂08-Dec-86 2239 RPG SUBSET
∂20-Nov-86 0439 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET SUBSET
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 Nov 86 04:39:48 PST
Received: from utokyo-relay by csnet-relay.csnet id ad19259; 20 Nov 86 5:36 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA02091; Thu, 20 Nov 86 19:11:39+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA11959; Thu, 20 Nov 86 19:03:53+0900
Date: Thu, 20 Nov 86 19:03:53+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8611201003.AA11959@ccut.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: SUBSET
I and JerryB communicated as for subsetting several times.
in his last message of Sept., he wrote
"I will consult Fahlman, RPG,.. to make a organization for subset in ANSI".
In Octber, he came to japan for his own business.
He and I had a promise to discuss about the matter with my subset committee.
But due to his personal accident, he only stayed 2days in japan and
had retuned USA. I could not meet and talk with him.
In the agenda for the commming X3 meeting,
Scope of X3J13 will not take subset into account or so.
It means the offical subset is not going to appear in USA ?
at least, for a while ?
I have a plan to gather software vendors who sells or will sell
'Common Lisp'-like -subset Lisps, to follow CL/Core in January.
And, I had thought the companies who selling/maintaining GCLisp might
join.
(Currently, main framers in japan are busy to implement their own
full-set Common Lisp. And in japan,
though Personal Computers have great influence for the people,
the softwares for PC including OS/language processors were
undertaken by ISV or the subsideries of main framers.)
Do you have any comments on it ?
Masayuki
∂08-Dec-86 2248 RPG from Japan
∂05-Nov-86 0337 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA from Japan
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Nov 86 03:36:47 PST
Received: from utokyo-relay by csnet-relay.csnet id dd00194; 5 Nov 86 1:28 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA04539; Tue, 4 Nov 86 23:11:45+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA17427; Tue, 4 Nov 86 22:57:05+0900
Date: Tue, 4 Nov 86 22:57:05+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8611041357.AA17427@ccut.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
ida%u-tokyo.junet@CSNET-RELAY.ARPA, mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: from Japan
***** This is not the official translation *****
On 1986 August 1st, MITI Japan announced the 3rd Japan-French round table
was to be held on Oct. 8th and 9th. at the meeting room of the MITI.
Oct.8th : morning. discussion by all the members
afternoon. working group discussion; AI, OSI, mechtronics, space industries, HA, Data base.
Oct. 9th working group discussions and lunchon
--------------------
AI group meeting at Oct 8th 14:00-18:00
from japan; 11 members(NEC,Fujitsu,OKI,Mitsubishi,JEDR,Toshiba,Hitachi,ICOT,MITI)
from France; 9 members(Act Informatique, Bull, Cognitec, Cril,Syseca,Telemecanique,Cescom,INRIA,DIELI)
1) Japan and France agreed to do information exchange about the standardization
on AI.
2) Japan and France agreed that Lisp is enough matured to be a subject of standardization.
3) France proposed to make INRIA as the correspondant.
France also asked japan to find the correspondant.
Japan agreed to search it.
4) France proposed to make an expert meeting for Lisp standardization.
Japan understood their will. But, japan declared it is too early.
japan explained japanese domestic efforts on standardization.
5) France claimed the objection to USA based standardization, especially
to Common Lisp.
6) France understood japanese way.
7) Mr. Simon of CRIL presented the objection to Common Lisp and claimed
Eulisp is good using the documents prepared by jerome chailloux.
------------------
Prof. Nakata, who will attend ISO SC22 meeting asked me the dirction. I
sent him a message,"please watch for a while. do'nt say yes to Eulisp."
(I need more a few months to persuade several old-timer Lisp researcher in
JIS committee)
-----------------
In these several months, Jeida Common Lisp committee have presentations of
Hitachi, Fujitsu, NEC about their own Common Lisp implementations. While,
JIS committee decided to make a JIS Lisp. We studied about the pros and
cons of Eulisp/Scheme. But, we feel if we will use Eulisp/scheme as a
base for JIS, it is too early to make JIS. also we feel Common Lisp is
suitable for current standard. The current issue is 100%common-lisp or
100% independent.
--------------------
Kanji working group of Jeida committee will finish their first draft on Kanji
related language extension in Jan.1987.
It will be appeared on IPSJ WGSYM meeting and Jeida report.
As soon as the document is available, I will send it to CL mail box.
Masayuki Ida
∂08-Dec-86 2249 RPG Lisp standardization
∂18-Sep-86 2047 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Lisp standardization
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Sep 86 20:47:05 PDT
Received: from utokyo-relay by csnet-relay.csnet id aj09430; 18 Sep 86 11:30 EDT
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA18188; Thu, 18 Sep 86 23:12:03+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA17403; Thu, 18 Sep 86 23:03:17+0900
Date: Thu, 18 Sep 86 23:03:17+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA>
Message-Id: <8609181403.AA17403@ccut.u-tokyo.junet>
To: Bobrow.pa%xerox.arpa@CSNET-RELAY.ARPA, fahlman@C.CS.CMU.EDU,
gls@ZARATHUSTRA.THINK.COM, ida%u-tokyo.junet@CSNET-RELAY.ARPA,
mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: Lisp standardization
Dear Bob Mathis,
Yesterday, I received a percel from you containing an agenda and
related documents for the comming ANSI meeting. Thank you.
As we discussed already, I can not attend the ANSI meeting on Sept.23,24,
because of my university schedule.
So, I describe the Japanese status as follows for your reference.
(and this is the reason why I sent this mail to Fahlman, gls, Dany, and Dick)
1) we had a second meeting of JIS LISP WG on Sept.5th.
The main issue was to determine the schedule and the scope.
I proposed three items, one is JIS LISP should be based on Common Lisp,
another is to make an international contribution as a JIS activity,
and the other is to make a draft and send it to MITI.
This WG has three years. We must finish WG on July 1989, which will conform to
the ISO schedule you proposed.
We have finally made a consensus that we will be based on Common Lisp,
after hot discussions !
2) As a researcher I have had a continous interest to CommonLoops since March 1985, one half years ago.
And as a chair I have played a role of the gate for the PCL distribution
and related things.
The number of the acknowledged holders of PCL in japan is (going to be) more than
10 organizations.
3) I was told by MITI stuff that ANSI asked MITI japan to investigate
the possibility of the joint efforts to make a joint standardization
on some items in Computer area.
MITI is now thinking of the LISP is suitable or no.
But they know the current status of Lisp area, becuase I told them.
And, Common Lisp is a candidate for the joint standardization.
Please push ANSI head office if you want to do so.
4) Jeida Common Lisp committee will make a second workshop on Common lisp on
Sept.19 and 20 (tomorrow).
This meeting will be also very important to the future of CL in japan.
Several mainframer will present their papers on their own Common Lisp (and CommonLoops !) implementation in the comming annual conferences of japanese
academic societies. I think its only a research level.
On the meeting we will have tomorrow,
a) the schedule of the Jeida proposal for the Kanji and the outline will be discussed. My private feeling is the target date is December 1986 or January 1987.
b) further policy for CL/Core will be decided. it should be only a specification ?
Or the pilot or the complete source will be jointly developed ?
The proposal from US implementors should be taken into ?
...
c) the schedule for the CommonLoops research group will be decided.
5) I received several mails from chaillou and Eulisp people.
I was surprised that they have a quite different feeling
on the result of the 'Tuesday night meeting'.
I adviced them that they should send their spec to european standardization
organization or should send to the computer manifactures to make the implementation.
I pray God that the everything is governed by God's will.
May God bless us.
Thank you
M.ida
ida%utokyo-relay.csnet@csnet-relay.arpa
∂09-Dec-86 1605 RICHER@SUMEX-AIM.ARPA X window system
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 86 16:05:45 PST
Date: Tue 9 Dec 86 16:03:11-PST
From: Mark Richer <RICHER@SUMEX-AIM.ARPA>
Subject: X window system
To: common-lisp@SU-AI.ARPA
cc: richer@SUMEX-AIM.ARPA
Message-ID: <12261524037.86.RICHER@SUMEX-AIM.ARPA>
I am interested in extensions to Commonlisp that are interfaced to the X
window system, especially using object-oriented programming. THere are groups
at Berkeley, Utah, and so on that are doing this right now. I am
putting together a mailing list on this and if you have something to share
or would just like to be on the list let me know. I guess if you are
interested in interfaces to SUN's new window system NEWS let me know
also.
Mark
-------
∂13-Dec-86 1653 RPG December minutes
∂10-Dec-86 0420 mcvax!ux63.bath.ac.uk!ma_jap@seismo.CSS.GOV December minutes
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 10 Dec 86 04:17:41 PST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA01669; Wed, 10 Dec 86 06:10:16 EST
From: mcvax!ux63.bath.ac.uk!ma_jap@seismo.CSS.GOV
Received: by mcvax.cwi.nl; Wed, 10 Dec 86 09:27:54 +0100 (MET)
Received: by inria.UUCP; Wed, 10 Dec 86 08:48:47 -0100 (MET)
Received: by inria.UUCP; Wed, 10 Dec 86 08:47:03 -0100 (MET)
Received: by mcvax.cwi.nl; Wed, 10 Dec 86 08:32:55 +0100 (MET)
Received: from hlh.uucp by eagle.Ukc.AC.UK with UUCP id a000898;
10 Dec 86 6:10 GMT
Mmdf-Warning: Parse error in original version of preceding line at Ukc.AC.UK
Date: Wed, 10 Dec 86 06:06:04 gmt
Message-Id: <13100.8612100606@hlh.co.uk>
Received: from bath63 by hlh.co.uk; Wed, 10 Dec 86 06:06:04 gmt
To: eulisp <eulisp@seismo.CSS.GOV>
Subject: December minutes
.sc
.ps 14
.vs 16
.ce
\fBMinutes of EuLISP-XIII, Paris, 861201\fP
.ps 10
.vs 12
\fBAttendees\fP
.nf
Thomas Bareiss, Siemens AG, Mu\*:nchen (TB)
Guy Benoliel, Cisi Te\*'le\*'matique, Paris (GB)
Olivier Blum, Cisi Te\*'le\*'matique, Paris (OB)
Je\*'ro\*↑me Chailloux, INRIA, Paris (JC)
Pierre Cointe, Universite\*' Paris VI (PC)
Jacques Duthen, IRCAM, Paris (JD)
J.L.Escudie\*', Cisi Te\*'le\*'matique, Paris (JLE)
John Fitch, University of Bath (JPF)
Mario Furmaru, Instituto di Cybernetica, Napoli (MF)
Richard Gabriel, Lucid Inc./Stanford University (RPG)
Klaus Hess, Siemens AG, Mu\*:nchen (KH)
Timm Krumnack, Krupps-Atlas Elektronik, Bremen (TK)
Thomas Manzke, Siemens AG, Mu\*:nchen (TM)
Eugen Neidl, CRCGE (EN)
Giancarlo Nota, Universita di Salerno (GN)
Julian Padget, University of Bath (JAP)
Pierre Parquier, Bull SA, Louveciennes (PP)
Willem van der Poel, University of Technology, Delft (WvdP)
Yves Potard, IRCAM, Paris (YP)
Christian Queinnec, Universite\*' Paris VI (CQ)
Herbert Stoyan, Universita\*:t Konstanz, (HS)
\fBAgenda\fP
1. Minutes of Eulisp-XII (Mainz)
2. Receive a report of the Vienna SC22 AG meeting
3. Rees' notice of the revisions to Scheme
4. Fahlman's &MORE proposal
5. Value cell paper for X3J13
6. Macros in Level0
7. Status of object oriented extensions to Common LISP
8. Funding
9. Future meetings
.fi
.fi
.ce
\fIMinutes of Eulisp-XII\fP
The minutes of the Mainz meeting were written up by Dieter Bartsch of
Insiders GmbH (the regular secretary having arrived late at the
meeting). Some factual errors were noted.
.ce
\fIVienna SC22 AG Meeting\fP
JC and HS reported on events at the Vienna meeting of SC22 AG
regarding the submission of new work items on LISP. Three new work
item proposals were made:
.ip (i)
the french member body (AFNOR) made a proposal based on the Eulisp
work
.ip (ii)
the american member body (ANSI) made a proposal based on the
wording which was developed between members of the Eulisp group and
various people from the US community at the meeting in Boston,
.ip (iii)
the american member body made a second proposal based on Common LISP.
.lp
SC22 AG recommended that the second proposal with AFNOR providing the
secretariat and the convenor and ANSI providing a project editor
should be put to a ballot of P-members. The result of this should be
known by February/March. Should this be approved a draft draft
proposal would have to be ready by January 1989. Again, should the
proposal be approved there should be a meeting of the working group
either in Milan (at IJCAI) or in Paris (at the object oriented
programming workshop) in the summer of next year.
There was some discussion about the methods of specification of the
standard and the consensus was that it might be advisable to
investigate the recommendations of ISO WG10, which reported recently.
There was a brief discussion about the name of the standard, bearing
in mind John McCarthy's expressed desire that a LISP standard should
not be called just LISP, during which no-one expressed dissent that
the ISO LISP standard should be called ISO-LISP.
The next meeting of SC22 AG will not be until November 1988, when the
status of the LISP working group will be officialised. It was seen to
be desirable to make sure that the informal working group should have
made a significant amount of progress by that time.
.ce
\fIScheme revisions\fP
There was a short discussion noting the revisions that have been made
in the latest version of the Revised**3 Report on Scheme (to be
published in SIGPLAN Notices in December 1986). In particular several
of the items highlighted in the Eulisp paper at Boston have been
addressed (no causal relationship implied), such as the provision of
PROCEDURE? and the removal of redundant comparison operations. Now
the only extension required to make Scheme be what is needed for
level0 is the addition of a type mechanism, which could be built on
top of rather than inside the language.
.ce
\fI&MORE proposal\fP
This was a proposal made by Scott Fahlman for handling an arbitrary
number of arguments. RPG reported that there was little response to
the idea on the Common LISP mailing list. JC reiterated the view that
multiple arguments and multiple results should be handled by a similar
mechanism. RPG referred to some work on the question by Wehyrauch and
Talcott in a language called Zeus. HS suggested that we should think
of multiple values in terms of windows of possiblity so (using the
example from CQ's discussion document of the level0/level1 evaluator):
.ce
(palindromep (foo x))
where foo returns a multiple value, would have the effect of passing
that multiple value result as a multiple value argument to palindromep
rather than
.ce
(multiple-value-call palindromep (foo x))
but then
.ce
(let ((x (foo x))) (palindromep x))
is not equivalent and the compiler must not convert the expression
into the first form or the meaning would change. This lead, in turn,
to a discussion of passing multiple arguments. RPG remarked that a
sufficiently smart compiler should be able to work it out, but warned
from experience with Common LISP, too much had been accepted on that
basis. The notion of multiple-argument-let (a means to name elements
of a multiple argument object) was discussed. It was not clear that
it was necessary (i.e. not proven through experience) and besides it
is not fundamental and the functionality could be provided through a
macro.
Following from this came a discussion about lambda keywords.
.ip &REST
Is this not an important facility. RPG remarked that &REST was very
rare in LUCID code and so the LUCID system uses CONSes to support it.
.ip &OPTIONAL
RPG remarked that this keyword is quite heavily used but has the
advantage that is can be handled by special casing in the entry
sequence. However, &OPTIONAL is very complicated when dispatching
methods for OOP and the consensus amongst that community is that only
methods with required arguments should be dispatchable.
.lp
.ce
\fIFunding\fP
JC reported that Patrick Rambert (INRIA) went to meet Omnes in
Bruxelles to discuss the question of EEC funding for the work of the
Eulisp group. Eulisp is one of four items currently under
consideration under the Esprit II initiative. Total money requested
is FF150K over the 1987 calendar year. It is unlikely that even if it
is approved that this will be available in time for the January
meeting. Under the proposal INRIA will act as a bank to support
existing members and also for Japanese and US participants.
RPG reported that he has been talking to the Dod to support (in a
financial manner) the X3J13 standardisation effort.
JAP reported that he has failed to get funding to attend the Dallas
meeting of X3J13. However, JC will be going.
.ce
\fIFuture Meetings\fP
January: a 2 day meeting, probably in den Haag (the Hague), to be
organised by WvdP for 5th-6th. If this is not possible, London will
be the fallback location.
February: also two days. Located in Paris, probably at IRCAM, for
9th-10th (because some participants have a programme committee
meeting at IRCAM on 11th).
March: Giancarlo Nota will talk to Luigio Aiello to investigate the
possibility of holding it in Rome.
.ce
\fIValue cell discussion\fP
RPG reported on the discussion document put together by Will Clinger,
Kent Pitman, RPG and several others for the Dallas X3J13 meeting.
Copies of the document were distributed.
RPG also reported that ARPA called a small meeting of interested
parties in the LISP and Scheme communities to see what grounds there
were for harmonising the languages and making Scheme effectively a
subset of Common LISP. Present were Mathis, Scherlis, Gabriel,
Steele, Fahlman, Clinger, Weinreb, Haflich and Sussman.
It was emphasised that the removal of the function cell from Common
LISP will make for the unification of CL and Scheme and for a
relatively straightforward layering of the language. Clearly there
will have to be changes in both CL and Scheme for each to accomodate
the other.
RPG summarised the advantages and disadvantages of removing the
function cell.
.ip Advantages:
cleaner language, no need for FUNCALL, no need for #', procedural
abstraction is freely available.
.ip Disadvantages:
Macros are an enduring problem, particularly wrt inadvertant capture
of free variables. This effect is minimised when programmers use FLET
and LABELS because they are more careful. The potential remains the
same, but in practice it is reduced.
Rewriting all macros to make sure they work in a single value system
would be very expensive.
There is little experience of new macro technology such as that
described in the appendix of the X3J13 discussion document.
Historically there were two name spaces because that was more
efficient. (Recent empirical tests by Fahlman suggest that the
efficiency gain now is no more than 10%).
A non-technical issue is that of commercial credibility of Common LISP
and the cost of conversion for the various vendors. However such a
change might be acceptable if phased in over a longer period (e.g. 5
years). The consensus was that a longer period seemed sensible. RPG
remarked that should such a plan be adopted the Dod might support
tools development in order to encourage the mixing of the ISO and the
ANSI efforts. CQ pointed out that 5 years would also fit in well with
ISO timescales, since it takes 2 years to get ISO acceptance, then
there is 3 years grace for conformance.
.lp
.ce
\fIMacros\fP
There was a wide-ranging discussion about the meaning of macros with
the main concern being the meaning of free variables in macros. There
are three situations to consider: definition, expansion, execution.
In CL there is a means to pass an environment for expansion to a macro
(&ENVIRONMENT) but this is not well specified, also the matter of
whether the argument list is a shared structure and what happens at
compilations are not clear. The SETF macros are treated
inconsistently (no &ENVIRONMENT option). The macro writing style in
CL leads to a heavy use of GENSYMs.
JAP briefly described the macro expansion mechanism in LISP/VM where
macros are expanded in a disjoint pushed-down environment. This has
the effect that their global environment is very limited and any
changes made in it are temporary (and no other expansion will see
them). It is very secure but at the same time limiting.
There was discussion about how much power was needed in macros at the
different levels. For instance simple substitution macros (to be
specified more precisely by HS) might suffice at level0. More
powerful systems could be built with the existence of environments as
first class items at the higher levels.
The issue of whether a macro should receive a copy of the argument was
not resolved.
The limitation of the LISP/VM model can be classified as a lack of a
capability to retain the altered environment and the overall problem
as a need for communication between environments. This lead to a
discussion of the ro\*↑le of environments, termed the expansion
environment and the continuation environment, and whether these should
roll on for ever or be reset. It was suggested that explicit
programmer control is necessary although that seems overly complex.
It is desirable to express the common behaviour as the default, namely
rolling on. The question of whether the macro expansion environment
should be disjoint from the user environment was not resolved.
JPF looked at the style of macro use to seek classification. He
suggested there are at least two forms: in models (i.e. how to
transform a structure without any conditions or external references)
and in DEFSTRUCTs (where it is necesary to extend the calling
environment with the structure accessor/update operators, etc.)
Traditionally, the use of macros in LISP has not been for textual
manipulation but for term manipulation.
The proposal at the end of the discussion was that level0 should have
substitution macros, level1 expansion in a separate environment,
level2 expansion in a specified environment. This is open to revision
after participants have considered the issues of the three kinds of
macro identified:
.ip (i)
to transform structure
.ip (ii)
to make a decision on the basis of the form of the structure
.ip (iii)
to make a decision on the basis of values in the structure and
externally
.lp
and have looked at the macro model developed by Kohlbecker.
.ce
\fIObject-oriented extensions\fP
RPG gave a status report on the work of unifying CommonLOOPS and New
Flavors. A draft is expected to be complete in mid January -
essentially the extension will be CommonLOOPS with method combination.
There will be a declarative syntax to specify calling sequences
(before, after) and result combination. The meta-object material
needs the most work yet.
As a consequence of this work there are some possible changes to CL,
such as the phasing out of DEFSTRUCT in favour of DEFCLASS and
DEFRECORD. A new first class item will be needed in Common LISP,
called generic function. JAP pointed out that the DEFCLASS mechanism
corresponds closely with the needs identified and serviced by the
level0 typing scheme which was very encouraging, since it highlighted
further common ground between the american and european efforts.
.ce
\fIAny Other Business\fP
There was a further short discussion of the Wahsington meeting on the
unification of CL and Scheme. First class environments and
continuations are seen as being entirely compatible introductions into
CL and no problems were envisaged. There also seems to be general
acceptance of the idea that free variables should default to
global/lexical and not special.
JAP suggested that the level0 evaulator as described by CQ was too
restrictive and that a data driven description would be better:
.ce
(defun eval (lambda (form) ((evalfn form) form)))
.ce
(defun apply (lambda (fn args) ((applyfn fn) args)))
and serve to focus attention on the relationship of the interpretation
of the object by associating the evaluation/application function with
its type (i.e. in the DEFSTRUCT - or whatever).
.ce
\fIFINIS - 1730\fP
.ce
\fIAction Items\fP
CQ will add macro expansion to the level0 interpreter
JAP will describe the interpreter outlined above in more detail
JAP will write and distribute the minutes
JC will report on events at X3J13 in Dallas
WvdP will seek to arrange the January meeting in the Netherlands and
contact JAP to arrange London as fallback as necessary
JAP to look at the LISP/VM STRUCT mechanism to see how the accessors
are generated
JAP to mail Clinger on LISP/VM macro expansion strategy
∂14-Dec-86 1956 RPG activities at JEIDA
∂14-Dec-86 1713 Owners-commonloops.pa@Xerox.COM activities at JEIDA
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Dec 86 17:13:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 DEC 86 16:49:56 PST
Return-Path: <@SUMEX-AIM.ARPA:SHOCHI.ISHIDA@NTT-20>
Received: from SUMEX-AIM.ARPA by Xerox.COM ; 14 DEC 86 16:48:50 PST
Received: from NTT-20 by SUMEX-AIM.ARPA with Cafard; Sun 14 Dec 86
16:40:55-PST
Date: Thu, 11 Dec 86 08:56:19
From: toru <shochi.ishida@NTT-20.ARPA>
Subject: activities at JEIDA
To: commonloops.pa%xerox.com@SUMEX-AIM.ARPA
cc: shochi.ishida@NTT-20.ARPA
Message-ID: <12261784928.21.SHOCHI.ISHIDA@NTT-20.NTT.JUNET>
We, the object oriented working group of JEIDA Common Lisp Committee,
had two full day meetings to discuss Common Lisp object oriented
facilities. Discussions were based on Portable CommonLoops (10/18/86).
Members in Attendance are:
Yutaka Hidai Toshiba
Masayuki Ida Aoyama Gakuin University
Toru Ishida NTT
Haruyuki Kawabe Nippon Univac
Taiji Nishida Fuji Xerox
Nobuyuki Saji NEC
Kazuo Takahashi Meidensha
Satoshi Uchida Aoyama Gakuin University
Makoto Yokoo NTT
Discussions are being continued, so I cannot summarize all of our
questions and comments here. Let me ask three questions, first.
<<1>> Masayuki Ida proposed to think about how to measure execution
speed of message passing. (One idea is to make a measurement unit
like LIPS of Prolog.) Does anyone plan to make benchmark programs for
this purpose?
<<2>> We found that the computing method of class precedence lists in
PCL is different from what is written in the OOPSLA'86 paper.
Consider the following example.
(ndefstruct (p (:class class) (:include (x a y))))
(ndefstruct (q (:class class) (:include (x b y))))
(ndefstruct (r (:class class) (:include (p q))))
(ndefstruct (s (:class class) (:include (r b a))))
(pcl::describe-class 'p)
The class #<Class P 11173640> is an instance of class #<Class CLASS 4443400>.
Name: P
Class-Precedence-List: (P X A Y OBJECT T)
Local-Supers: (X A Y)
Direct-Subclasses: (R)
#<Class P 11173640>
(pcl::describe-class 'q)
The class #<Class Q 11173540> is an instance of class #<Class CLASS 4443400>.
Name: Q
Class-Precedence-List: (Q X B Y OBJECT T)
Local-Supers: (X B Y)
Direct-Subclasses: (R)
#<Class Q 11173540>
(pcl::describe-class 'r)
The class #<Class R 11173440> is an instance of class #<Class CLASS 4443400>.
Name: R
Class-Precedence-List: (R P A Q X B Y OBJECT T)
Local-Supers: (P Q)
Direct-Subclasses: (S)
#<Class R 11173440>
(pcl::describe-class 's)
The class #<Class S 11173340> is an instance of class #<Class CLASS 4443400>.
Name: S
Class-Precedence-List: (S R P Q X Y B A OBJECT T)
Local-Supers: (R B A)
Direct-Subclasses: NIL
#<Class S 11173340>
According to OOPSLA'86 paper, the algorithm of CommonLoops is:
left to right, depth first up to joins
with the constraint that the local ordering of
any local precedence list must be maintained.
However, it seems that PCL does not maintain the local orderings.
Which is the correct interpretation of CommonLoops?
The class-precedence-list of <r> is:
a) (r p a q x b y), as PCL works right now.
b) (r p q x a b y), because it preserves all of the local
orderings.
c) signal an error, because (p x a y) and (q x b y) are not compatible.
The class-precedence-list of <s> is
d) (s r p q x y b a), as PCL works right now.
e) (s r p q x b a y), because it preserves all of the local
precedence lists.
f) signal an error, because (r p a q x b y) or (r p q x a b y) and (s b a)
are not compatible.
<<3>> We are interested in the order of pre-made discriminating
functions, which is specified in dfun-templ. Is it based on some
statistical analysis?
Toru ishida
-------
∂15-Dec-86 0456 RWK@YUKON.SCRC.Symbolics.COM FILE-WRITE-DATE, FILE-AUTHOR
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 15 Dec 86 04:56:41 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134642; Mon 15-Dec-86 07:54:51 EST
Date: Mon, 15 Dec 86 07:54 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: FILE-WRITE-DATE, FILE-AUTHOR
To: common-lisp@SU-AI.ARPA
cc: toto@YUKON.SCRC.Symbolics.COM, cal@THINK.COM
Message-ID: <861215075436.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
FILE-WRITE-DATE and FILE-AUTHOR are both vague on what
happens if the file does not exist. The text says:
@I[file] can be a filename or a stream that is open to a file.
This returns the time at which the file was created or last
written as an integer in universal time format (see section 25.4.1),
or NIL if this cannot be determined.
(FILE-AUTHOR is similar).
My reading of this is that the phrase "if this cannot be determined"
means "determined by looking at the file", not "determined for any
reason". I think the intent here is to cover such situations as
an operating system which doesn't support creation dates, or a
network link which doesn't support inquiring about dates.
Situations like giving the wrong pathname, temporary network failure,
or no access rights should signal an error.
PROBE-FILE and DIRECTORY are also a bit vague on these matters, saying
nothing about what happens when you can't inquire about files due to
network failure or no access rights.
I also think that if the directory doesn't exist, you should get an
error, not just return NIL, but this would need to wait until we have an
error system, or the incompatibility would be too large.
USER-HOMEDIR-PATHNAME says "if it is impossible to determine this
information, then NIL is returned instead of a pathname;". It's
not clear whether this means "is impossible right now due to a
system error" or "is impossible to inquire of that host". Returning
NIL due to a transient condition is both uninformative to the user
and may lead to suprising behaviour, like reading in the wrong files
or refusing to do something.
The :IF-DOES-NOT-EXIST NIL option to OPEN does not say what it
does about things like network errors, etc.
A lot of people seem to assume that if CLtL doesn't say anything
about errors, then a function may not signal any errors, even if
something goes wrong. Hopefully the new error system standard will
address a lot of these issues, but some clarification (or at least
agreement on the intent) would help now.
∂15-Dec-86 1354 masinter.pa@Xerox.COM Re: FILE-WRITE-DATE, FILE-AUTHOR
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Dec 86 13:54:12 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 DEC 86 13:52:51 PST
Date: 15 Dec 86 13:45 PST
From: masinter.pa@Xerox.COM
Subject: Re: FILE-WRITE-DATE, FILE-AUTHOR
In-reply-to: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>'s message of
Mon, 15 Dec 86 07:54 EST
To: RWK@YUKON.SCRC.Symbolics.COM
cc: common-lisp@SU-AI.ARPA, cal@THINK.COM
Message-ID: <861215-135251-3226@Xerox>
The error system proposal (aka the Condition System proposal) does not
at all address the issue of what functions might specify what errors, it
only provides a mechanism by which the type of error might be specified,
and for handling such conditions.
This is my attempt to summarize the issue you brought up:
"There are several operations in Common Lisp (e.g., PROBE-FILE,
DIRECTORY, OPEN) for which CLtL is vague about the behavior in the face
of lack of access rights, network failures, or transient conditions.
The alternatives are to
a) to declare that these conditions should be treated within the bounds
of the specified operation, e.g., that PROBE-FILE return as if the file
were not present, USER-HOMEDIR-PATHNAME, FILE-WRITE-DATE, FILE-AUTHOR
return NIL
b) to declare explicitly that the behavior of a Common Lisp
implementation in such conditions is "unspecified" or
"implementation-dependent"
c) to define conditions (e.g., INTERMITTENT-FILE-ERROR,
INSUFFICIENT-ACCESS-RIGHTS) which will be signalled when such conditions
arise, and, perhaps, some of the actions that should happen surrounding
such signals (e.g., that it should be possible to specify that
FILE-WRITE-DATE should just return NIL if it is not available, ect.)
- - - - - - - - - - - -
Independent of the merits of one proposal over another, are there any
other proposals or refinements of these? Other functions and situations
(besides FILE-WRITE-DATE, FILE-AUTHOR, PROBE-FILE, DIRECTORY, OPEN,
USER-HOMEDIR-PATHNAME)?
∂16-Dec-86 1220 RWK@YUKON.SCRC.Symbolics.COM Re: FILE-WRITE-DATE, FILE-AUTHOR
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 16 Dec 86 12:20:36 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135903; Tue 16-Dec-86 15:18:27 EST
Date: Tue, 16 Dec 86 15:17 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: FILE-WRITE-DATE, FILE-AUTHOR
To: masinter.pa@Xerox.COM
cc: RWK@YUKON.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA, cal@THINK.COM
In-Reply-To: <861215-135251-3226@Xerox>
Message-ID: <861216151753.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
A good summary. I'd add another option:
d) Declare that they signal an error when they were actually
unable to determine the existance of the file. This is not
quite as satisfactory as item 'c', but is a reasonable holding
action until the error system proposal is adopted and attention
is given to standardizing on specific conditions and circumstances.
Date: 15 Dec 86 13:45 PST
From: masinter.pa@Xerox.COM
The error system proposal (aka the Condition System proposal) does not
at all address the issue of what functions might specify what errors, it
only provides a mechanism by which the type of error might be specified,
and for handling such conditions.
This is my attempt to summarize the issue you brought up:
"There are several operations in Common Lisp (e.g., PROBE-FILE,
DIRECTORY, OPEN) for which CLtL is vague about the behavior in the face
of lack of access rights, network failures, or transient conditions.
The alternatives are to
a) to declare that these conditions should be treated within the bounds
of the specified operation, e.g., that PROBE-FILE return as if the file
were not present, USER-HOMEDIR-PATHNAME, FILE-WRITE-DATE, FILE-AUTHOR
return NIL
b) to declare explicitly that the behavior of a Common Lisp
implementation in such conditions is "unspecified" or
"implementation-dependent"
c) to define conditions (e.g., INTERMITTENT-FILE-ERROR,
INSUFFICIENT-ACCESS-RIGHTS) which will be signalled when such conditions
arise, and, perhaps, some of the actions that should happen surrounding
such signals (e.g., that it should be possible to specify that
FILE-WRITE-DATE should just return NIL if it is not available, ect.)
- - - - - - - - - - - -
Independent of the merits of one proposal over another, are there any
other proposals or refinements of these? Other functions and situations
(besides FILE-WRITE-DATE, FILE-AUTHOR, PROBE-FILE, DIRECTORY, OPEN,
USER-HOMEDIR-PATHNAME)?
∂18-Dec-86 1020 RPG Getting things rolling
∂17-Dec-86 2008 FAHLMAN@C.CS.CMU.EDU Getting things rolling
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 86 20:08:05 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 17 Dec 86 23:02:08-EST
Date: Wed, 17 Dec 1986 23:02 EST
Message-ID: <FAHLMAN.12263664667.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: gls@ZARATHUSTRA.THINK.COM, masinter.pa@XEROX.COM,
"DCM%HPFCLP"@HPLABS.HP.COM, KMP@SCRC-STONY-BROOK.ARPA,
"edsel!jonl"@NAVAJO.STANFORD.EDU, fahlman@C.CS.CMU.EDU
Cc: rpg@SAIL.STANFORD.EDU, Mathis@[26.6.0.103], moon@SCRC-STONY-BROOK.ARPA
Subject: Getting things rolling
OK, now that we're all recovered from Dallas, I guess it's time to get
things rolling in this cleanup committee. The mailing addresses above
are from Gabriel's X3J13 file, so presumably they all work. We'll see.
For now, we can probably just stick these names on each message
instead of setting up a re-mailing system.
I've included RPG and Mathis on the theory that someone ought to monitor
all the committee mail, just to make sure that the groups neither
overlap nor develop serious gaps between them. I don't know who wants
to do this, but until it is decided, I thought it best to put the
proto-officer-nominees in that position.
I've contacted Dave Moon to see if he wants to participate in this
committee. He was very active before and I think he would be a very
valuable addition if he wants to spend the time. I gather that he would
have been at Dallas, but for some last-minute problems. If there are
some other people who were not at Dallas, but who might be valuable
additions to this list, please suggest them. Let's not inflate it too
much, however, until we develop a feeling for what procedures are
workable.
My own view is that we want to set up a sort of tree structure to handle
this. We should elect someone chairman of this committee, and it would
be his job to coordinate and prod things along. He should probably also
keep the lists of issues to be resolved, proposals that are being
considered, and things we've settled. The other committee members would
each take responsibility for formulating proposals on some set of
issues, and we would all review the proposals as they come in. Each of
us can involve whatever friends and assistants we might have to get
our proposals worked out, debugged, and described coherently. So we've
got a sort of tree structure from the chairman to all of us to whoever
we recruit.
Once we've got proposals we like (or a coherent set of alternatives), I
suppose we should run these past the Common Lisp mailing list. I
suggest that we put out a big batch of proposals at once, harvest any
good ideas or useful criticisms, go back into committee, and make
modifications there. We should probably not answer every comment, get
into debates on the Common Lisp mailing list, or encourage others out
there to debate among themselves. We'll have to move very cautiously to
avoid a repeat of last summer's mail storm.
Then we take the proposals (as modified) to X3J13, and at that point the
formal checks and balances start. Because these are so extensive, I
think we can get away with something much less formal on the big mailing
list -- the view should be that we are drafting proposals, and that we
are occasionally asking the big mailing list to help us in drafting
those proposals.
It would be nice to have a batch of easy things ready for the February
pre-notification deadline that precedes the next meeting, whenever that
is. Having some concrete proposals next time would make everyone feel
good. But it may be that all we'll have is a progress report -- we
shouldn't press for quick results if it means going off half-cocked.
Those are just my own suggestions -- please feel free to comment or
counter-propose.
For myself, I would prefer not to be the chairman, so that I can spend
more time on the technical side of things. I will spend some time in
the next couple of weeks to clean up and organize the materials and
issues I gathered last summer, and I plan to work on a good share of the
proposals, but I'd prefer not to be the coordinator on this. Is anyone
out there willing to do this job? If we get more than one candidate, we
could even have an election.
-- Scott
∂18-Dec-86 1023 RPG Re: Getting things rolling
∂17-Dec-86 2147 masinter.pa@Xerox.COM Re: Getting things rolling
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 17 Dec 86 21:47:07 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 17 DEC 86 21:42:31 PST
From: masinter.pa@Xerox.COM
Date: 17 Dec 86 21:40:31 PST
Subject: Re: Getting things rolling
In-reply-to: FAHLMAN@C.CS.CMU.EDU's message of Wed, 17 Dec 86 23:02 EST,
<FAHLMAN.12263664667.BABYL@C.CS.CMU.EDU>
To: FAHLMAN@C.CS.CMU.EDU
cc: gls@ZARATHUSTRA.THINK.COM, masinter.pa@Xerox.COM,
"DCM%HPFCLP"@HPLABS.HP.COM, KMP@SCRC-STONY-BROOK.ARPA,
"edsel!jonl"@NAVAJO.STANFORD.EDU, rpg@SAIL.STANFORD.EDU (Mathis),
moon@SCRC-STONY-BROOK.ARPA
Message-ID: <861217-214231-5875@Xerox>
I'm willing to be chairman as long as I can postpone doing work on it
until after the first of the year. I believe I will be able to spend the
time it will take at that point.
∂18-Dec-86 1328 RPG Re: Getting things rolling
∂18-Dec-86 1259 Masinter.pa@Xerox.COM Re: Getting things rolling
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Dec 86 12:59:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 DEC 86 12:33:04 PST
Date: 18 Dec 86 12:32 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Getting things rolling
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Wed,
17 Dec 86 23:02 EST
To: Fahlman@C.CS.CMU.EDU
cc: gls@ZARATHUSTRA.THINK.COM, masinter.pa@Xerox.COM,
"DCM%HPFCLP"@HPLABS.HP.COM, KMP@SCRC-STONY-BROOK.ARPA,
"edsel!jonl"@NAVAJO.STANFORD.EDU, rpg@SAIL.STANFORD.EDU, (Mathis)
moon@SCRC-STONY-BROOK.ARPA
Message-ID: <861218-123304-6436@Xerox>
(I'm using a different mailer, perhaps this one will work better. I
still can't send mail to the Mathis address, however.) I like Scott's
idea of delegating issues for exposition, and controlling the use of the
Common Lisp mailing list. I have some additional proposals:
It will help to establish some general guidelines for proposals. For
each issue, there are a set of options for resolving the issue. For each
option, we can ask, e.g. :
a) Does it help with portability (e.g., defining something which is
currently undefined).
b) is it compatible with current implementations (e.g., not explicitly
stated in the book, but all implementations have chosen to do it) If
not, is there a transition plan for implementations (e.g., a way of
implementing the new feature in terms of the old.)
c) is it compatible with current practice (e.g., an extension which
doesn't exist in most implementations would not break user code). If
not, is there a transition plan for users (e.g., a way of getting
functionality which we decide to remove from the standard)
I would hope that we could get consensus on how each alternative stacks
up against various evaluation criteria, even if there is not consensus
on which alternative was preferable.
We would use the Common Lisp mailing list primarily to solicit issues,
and, when necessary, to look for alternatives.
What we can bring before X3J13 would then be a document outlining
Issue: a description of what the problem is
Alternatives: a list of the alternative solutions, along with some
evaluation of the alternative
Recommendation: the vote of this subcommittee on which alternative is
preferable. Unless we all agree, we can report votes directly (who voted
for which alternative).
∂18-Dec-86 1346 RPG Cleanup
∂18-Dec-86 1342 FAHLMAN@C.CS.CMU.EDU Cleanup
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 86 13:42:14 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 18 Dec 86 16:41:01-EST
Date: Thu, 18 Dec 1986 16:40 EST
Message-ID: <FAHLMAN.12263857403.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: gls@ZARATHUSTRA.THINK.COM, masinter.pa@XEROX.COM,
hpfclp!dcm@HPLABS.HP.COM, KMP@SCRC-STONY-BROOK.ARPA,
"edsel!jonl"@NAVAJO.STANFORD.EDU, fahlman@C.CS.CMU.EDU
cc: rpg@SAIL.STANFORD.EDU, Mathis@[26.6.0.103], moon@SCRC-STONY-BROOK.ARPA
Subject: Cleanup
[Maybe this address will get to Matthews better. I sent a test message
earlier and got no answer, but also no complaint from the mailer.]
I like Larry's suggestions. Another thing we might want to do, as much
as possible, is to separate the fixing of ambiguities and
inconsistencies in the manual from proposed small changes and additions,
and deal with the cleanup stuff first. Once we're rolling properly,
then we can thing about little changes that people would probably agree
to, but that aren't absolutely essential to having a well-defined
language.
During the abortive attempt to fix thing sup last summer, I allowed the
current topics on the mailing list to drive the order of proposals to
some extent, and that was a mistake: we ended up considering extensions
before true cleanup items. This time, we're free to order the issues
more rationally.
-- Scott
∂18-Dec-86 1513 ELIOT%cs.umass.edu@RELAY.CS.NET File Operations
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Dec 86 15:13:05 PST
Received: from cs.umass.edu by csnet-relay.csnet id ao02299; 18 Dec 86 17:29 EST
Date: Thu, 18 Dec 86 12:03 EDT
From: ELIOT%cs.umass.edu@RELAY.CS.NET
To: Common-Lisp@SU-AI.ARPA
Subject: File Operations
X-VMS-To: CSNET%"Common-Lisp@su-ai.arpa"
File Operation errors are somewhat of a special case, in that
a "correct" program may attempt an uncompletable file operation.
Some of the operations in question are exactly the operations which
must be performed in order to determine if the operations can be done.
(E.g. Probe-file.)
Because of this I think that special handling of errors is called for.
I would suggest that keyword arguments be added to these functions
which control this behavior. I would propose two new arguments,
:on-error and :on-failure. Failure is defined as a reasonable operation
that couldn't be done because of some condition in the outside world,
such as a network being down. Errors are operations that don't seem
to make sense, such as deleting a file that does not exist, or
supplying a host name that is unknown. The values to the keyword
arguments would be :error
arguments would be :ERROR or a value to return. (With :ERROR being
the default.) A value of :ERROR would indicate that an error should
be signalled.
This is obviously redundant with handling these situations in the error
system. However, we won't have an error system generally implemented
for quite some time. Even then this crude would be useful in simpler
situations, and I think it would be easier to read:
(probe-file foo :on-failure nil)
Than:
(condition-bind
(si:file-operation-failure nil)
(probe-file foo))
Since file operation errors are so pervasive the redundant functionality
would be worth it.
∂18-Dec-86 1625 Moon@STONY-BROOK.SCRC.Symbolics.COM File Operations
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Dec 86 16:24:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 27691; Thu 18-Dec-86 19:22:32 EST
Date: Thu, 18 Dec 86 19:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: File Operations
To: ELIOT%cs.umass.edu@RELAY.CS.NET
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 18 Dec 86 11:03 EST from ELIOT%cs.umass.edu@RELAY.CS.NET
Message-ID: <861218192211.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 18 Dec 86 12:03 EDT
From: ELIOT%cs.umass.edu@RELAY.CS.NET
....
Because of this I think that special handling of errors is called for.
I would suggest that keyword arguments be added to these functions
which control this behavior.
....
This is obviously redundant with handling these situations in the error
system. However, we won't have an error system generally implemented
for quite some time.
I don't understand why this change to Common Lisp would receive widespread
implementation earlier than the error-handling facility change to Common
Lisp. Either way it's different from what people have implemented now.
At Symbolics, and earlier at MIT, we have had a lot of experience with
error handling, especially in file system operations. We used to use an
enable-error argument scheme similar to what you suggest, but found it
to be unsatisfactory and switched to a uniformly condition-based scheme.
∂19-Dec-86 0924 @MIT-LIVE-OAK.ARPA,@PALLADIAN-JASPER.LCS.MIT.EDU,@WHITBY.Palladian.COM:dfm@PALLADIAN-JASPER.LCS.MIT.EDU sharp plus question
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:24:23 PST
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 22488; 19 Dec 86 12:24:06-EST
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via CHAOS with SMTP id 22232; 19 Dec 86 11:59:36-EST
Date: Fri, 19 Dec 86 11:59 EST
From: Don Morrison <dfm@JASPER.Palladian.COM>
Reply-To: DFM%JASPER@LIVE-OAK.LCS.MIT.EDU
Subject: sharp plus question
To: common-lisp@su-ai.arpa
cc: dfm@JASPER.Palladian.COM
Message-ID: <861219115917.5.DFM@WHITBY.Palladian.COM>
What should the second form in the following read as?
(push :mumble *features*)
'(#-mumble #+mumble 1 2 3)
I would expect '(2 3). Both implementations I've tried read '(3), which
is completely unintuitive to me. Such a thing can easily come up in real
life (e.g. commenting out with #+(or) something that's already under
#+mumble).
Don Morrison
Palladian Software, Inc.
[I'm not sure what the current state of our mailer is, but I think mail
addressed to DFM%JASPER@LIVE-OAK.LCS.MIT.EDU will eventually get to me.]
∂19-Dec-86 0957 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM sharp plus question
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:56:18 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39609; Fri 19-Dec-86 12:54:41 EST
Date: Fri, 19 Dec 86 12:53 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: sharp plus question
To: DFM%JASPER@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA
cc: dfm@JASPER.Palladian.COM
In-Reply-To: <861219115917.5.DFM@WHITBY.Palladian.COM>
Message-ID: <861219125356.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Fri, 19 Dec 86 11:59 EST
From: Don Morrison <dfm@JASPER.Palladian.COM>
What should the second form in the following read as?
(push :mumble *features*)
'(#-mumble #+mumble 1 2 3)
I would expect '(2 3). Both implementations I've tried read '(3), which
is completely unintuitive to me. Such a thing can easily come up in real
life (e.g. commenting out with #+(or) something that's already under
#+mumble).
Don Morrison
Palladian Software, Inc.
This is curious. In the Symbolics 7.0 implementation,
'(#+non-existent-feature #-non-existent-feature 1 2 3)
'(#-non-existent-feature #+non-existent-feature 1 2 3)
'(#+LISPM #-LISPM 1 2 3)
each read as '(2 3) but
'(#-LISPM #+LISPM 1 2 3)
does read as '(3). This does seem wrong on the following grounds:
#-LISPM goes into the mode "read me a form, and ignore it." It
recursively invokes the reader.
The reader gets #+LISPM. #+LISPM goes into the mode "read
me a form and don't ignore it." This recursively invokes
the reader.
The reader reads 1.
#+LISPM does not ignore the 1, so it returns it as the thing
read.
#-LISPM is given 1 as the result of the read, and ignores it.
2 and 3 are still in the input stream, so I don't know how both
of them manage to get ignored.
[I'm not sure what the current state of our mailer is, but I think mail
addressed to DFM%JASPER@LIVE-OAK.LCS.MIT.EDU will eventually get to me.]
∂19-Dec-86 1222 KMP@STONY-BROOK.SCRC.Symbolics.COM FOLLOW-SYNONYM-STREAM
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86 12:22:04 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28330; Fri 19-Dec-86 15:20:50 EST
Date: Fri, 19 Dec 86 15:19 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FOLLOW-SYNONYM-STREAM
To: Common-Lisp@SAIL.STANFORD.EDU
Message-ID: <861219151955.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
From time to time, I find myself doing:
(LET ((*TERMINAL-IO* *STANDARD-OUTPUT*))
...)
in a multi-window system in order to temporarily change my interaction to the
same window as output has been redirected to. On the Lisp Machine (and probably
on many or most other implementations), *STANDARD-OUTPUT* can sometimes (often)
contain a synonym-stream for *TERMINAL-IO* and the result of the operation
above is to send output to a stream which is a (circular) synonym for itself.
The kind of lossage this results in is fairly severe because *DEBUG-IO* is often
a synonym for *TERMINAL-IO* and if that is in turn a synonym for *TERMINAL-IO*,
then the debugger cannot run.
A couple of things would make this problem more tractable:
SYNONYM-STREAM-P object [Function]
This accepts any kind of argument. If the argument is not a synonym
stream, then NIL is returned. If the argument is a synonym stream,
then the symbol for which the object is a synonym is returned.
FOLLOW-SYNONYM-STREAM stream [Function]
This accepts a stream and returns the result of following that stream
through any number of synonym stream indirections (including zero).
While I'm on page 329, I think we should also have the following functions
(or functionalities) which I have needed at other times:
BROADCAST-STREAM-P object [Function]
CONCATENATED-STREAM-P stream [Function]
TWO-WAY-STREAM-P [Function]
...
This accepts any kind of argument. It returns T if the argument is a
{concatenated/broadcast/two-way/...} stream and NIL if the argument is
any other kind of stream.
EXPAND-BROADCAST-STREAM broadcast-stream [Function]
EXPAND-CONCATENATED-STREAM concatenated-stream [Function]
EXPAND-TWO-WAY-STREAM two-way-stream [Function]
...
This accepts a {broadcast/concatenated/two-way/...} stream and returns
a list of the streams which were used to compose it (in an order
compatible with the order of arguments to the creation function).
Note: Implementations are allowed, but not required, to return the
same list every time. The result list should not be destructively modified.
∂20-Dec-86 1216 RPG ISO Lisp WG meetings
∂20-Dec-86 0807 MATHIS@ADA20.ISI.EDU ISO Lisp WG meetings
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 Dec 86 08:06:25 PST
Date: 20 Dec 1986 07:47-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: ISO Lisp WG meetings
From: MATHIS@ADA20.ISI.EDU
To: rpg@SAIL.STANFORD.EDU
To: willc%tekchips.tek@RELAY.CS.NET
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU]20-Dec-86 07:47:16.MATHIS>
Dick and Will, If the French want to have the first ISO meeting
in Paris on June 18 and 19, that's OK with me. I would rather
have had it in conjuction with IJCAI, but I don't always get my
way. But I also think it would be too soon to have the second ISO
meeting in August at IJCAI. It would be nice to establish a
precedent that we didn't have two meetings in a row in Europe.
Why don't we invite them to Washington (or someplace else on the
east coast) in the Fall of 1987? -- Bob
/sub
Mathis@ADA20.ISI.EDU,"willc%tekchips.tek"@RELAY.CS.NET
ISO WG
This sounds fine to me. I'd be slightly happier with the first ISO WG
meeting being held in Milan because it minimizes my European travel during the
summer. Certainly it seems as though we should establish a tradition
of having these meetings on both sides of the Atlantic, but I suspect
there might be power playing when the Europeans see the X3J13 statement
of purpose, whose contents is indistinguishable from a declaration of
war, from their perspective.
I spent a number of hours trying to show Jerome that the contents of
the purpose reflected some political realities in the US with respect
to users. In fact, when I took Jermone to the airport to return to Paris
he said the primary thing he learned was that there was a strong user-community
influence on Common Lisp that he had not realized. I hope he didn't forget
that on the plane.
I've booked a flight to Munich for POPL (Jan 20) in case it becomes
necessary to mount a peace initiative then. Wegman will be in Munich as
well, so a meeting might be profitable.
I hope your holiday season is enjoyable.
-rpg-
∂21-Dec-86 1523 nelson%bach.DEC@decwrl.DEC.COM #+/-
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 21 Dec 86 15:23:07 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA21974; Sun, 21 Dec 86 15:23:14 PST
Message-Id: <8612212323.AA21974@decwrl.dec.com>
Date: Sunday, 21 Dec 1986 15:22:29-PST
From: nelson%bach.DEC@decwrl.DEC.COM (Beryl Elaine Nelson)
To: common-lisp@su-ai.ARPA, dfm%bach.DEC@decwrl.DEC.COM
Subject: #+/-
(This is in response to Don's message about nesting #+ and #-)
VAX LISP returns a two-element list whether the #+ or #- is first.
I believe that this behaviour is correct; it seems logical to
consider the second # macro to apply to the first form to be read (1),
and the first # macro form apply to the first remaining form to
be read (1 if it hasn't been removed already, or 2 if 1 has been
removed).
Lisp> (push 'foo *features*)
(FOO EDITOR SYSTEM-EDITOR::INTERNAL-BUILD UIS COMPILER DEBUGGER VMS DEC COMMON VAX)
Lisp> '(#-foo #+foo 1 2 3)
(2 3)
Lisp> '(#+foo #-foo 1 2 3)
(2 3)
Beryl Nelson
nelson%bach@decwrl.dec.com
∂22-Dec-86 0611 @DIAMOND.S4CC.Symbolics.COM:Greenwald@STONY-BROOK.SCRC.Symbolics.COM sharp plus question
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 22 Dec 86 06:10:54 PST
Received: from SWALLOW.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39985; Mon 22-Dec-86 09:09:17 EST
Date: Mon, 22 Dec 86 09:08 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: sharp plus question
To: DCP@QUABBIN.SCRC.Symbolics.COM, DFM%JASPER@LIVE-OAK.LCS.MIT.EDU,
common-lisp@SU-AI.ARPA
cc: dfm@JASPER.Palladian.COM
In-Reply-To: <861219125356.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Message-ID: <861222090840.6.GREENWALD@SWALLOW.S4CC.Symbolics.COM>
Date: Fri, 19 Dec 86 12:53 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Fri, 19 Dec 86 11:59 EST
From: Don Morrison <dfm@JASPER.Palladian.COM>
What should the second form in the following read as?
(push :mumble *features*)
'(#-mumble #+mumble 1 2 3)
I would expect '(2 3). Both implementations I've tried read '(3), which
is completely unintuitive to me. Such a thing can easily come up in real
life (e.g. commenting out with #+(or) something that's already under
#+mumble).
Don Morrison
Palladian Software, Inc.
This is curious. In the Symbolics 7.0 implementation,
'(#+non-existent-feature #-non-existent-feature 1 2 3)
'(#-non-existent-feature #+non-existent-feature 1 2 3)
'(#+LISPM #-LISPM 1 2 3)
each read as '(2 3) but
'(#-LISPM #+LISPM 1 2 3)
does read as '(3). This does seem wrong on the following grounds:
#-LISPM goes into the mode "read me a form, and ignore it." It
recursively invokes the reader.
The reader gets #+LISPM. #+LISPM goes into the mode "read
me a form and don't ignore it."
Currently, the Symbolics' reader treats both #+ and #- as "ignore next
form" when *READ-SUPPRESS* is T. This is probably a misinterpretation
of *READ-SUPPRESS*. It was done to solve the problem of an illegally
formed expression following a #+ inside a form with *READ-SUPPRESS* 'T.
For example,
(PROGN
#+IMPLEMENTATION-X
(INCF (FROB-KNOB GROZZLE)
#+SYS:GREEPS-ALLOWED 3
#-(CAR FGR:*GROZZLE-MODES*) 2)
....)
Is the correct interpretation to obey #+ and #- even inside a
*READ-SUPPRESS*? (while still suppressing errors inside the feature
specification?)
Clearly #+NON-FEATURE (A B #-NON-FEATURE C), shouldn't cause read errors
while reading C.
The question is whether the internal "feature specification" should be
read with *READ-SUPPRESS* bound specially to NIL or not.
If we keep the current binding of *READ-SUPPRESS*, then feature will
always be NIL (*READ-SUPPRESS* causes all extended tokens to be NIL).
If we bind *READ-SUPPRESS* to NIL to read the feature specification,
then syntactic "errors" in the feature can cause errors.
The problem of supporting (by ignoring) non-standard syntax in feature
specifications doesn't need to be part of COMMON-LISP (I don't think
CL allows extensions there), the question of nested #-'s does need to be
made unambiguous.
Implementations (Symbolics' for example) that want to be generous in
what they accept without error, can handle that themselves.
This recursively invokes
the reader.
The reader reads 1.
#+LISPM does not ignore the 1, so it returns it as the thing
read.
#-LISPM is given 1 as the result of the read, and ignores it.
2 and 3 are still in the input stream, so I don't know how both
of them manage to get ignored.
[I'm not sure what the current state of our mailer is, but I think mail
addressed to DFM%JASPER@LIVE-OAK.LCS.MIT.EDU will eventually get to me.]
I'm not on the COMMON-LISP mailing list, but someone from Symbolics can
forward to me any replies, if there is some trouble with the return
paths.
∂22-Dec-86 1511 RPG Re: minutes of Dallas meeting
∂22-Dec-86 1444 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Re: minutes of Dallas meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 22 Dec 86 14:44:13 PST
Received: from utokyo-relay by csnet-relay.csnet id af00566; 22 Dec 86 15:57 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA17067; Mon, 22 Dec 86 15:32:58+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA08677; Mon, 22 Dec 86 15:26:58+0900
Date: Mon, 22 Dec 86 15:26:58+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8612220626.AA08677@ccut.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: Re: minutes of Dallas meeting
Dear Bob Mathis,
Our center will stop during Dec.26 to Jan.5.
So, I want to receive a preliminary version before our winter vacation.
Let me explain our status.
1. JIS committee
we are discussing about what is the best for japan. Though the main load
is fixed on Common Lisp, several persons want to look at european will do.
MITI asked us to be an official committee to France with the push from France
government. (US government have no idea to do a same thing to MITI ? )
We made a vote and decided to do it because our request was accepted.
that is, the communication is passive and we will not make any joint project
as-of-now, and only postal communication will be there.
We discussed about Eulisp, Scheme and the pros and cons of Common Lisp.
As I told earlier, until March we will have this type of buzz.
We are now discussing about the function/value issue again.
2. ISO
Prof. Nakata who is the member of ISO SC22 from japan, has a feeling that
international matters are with europe. Several other senior professor wonder
which is the true. I mean I say Common Lisp is the industrial standard and
ISO related news says Franch is so energetic to make an international standard
based on the european activities.
3. Jeida Common Lisp committee
we had presentations from Hitachi, Fujitsu, and NEC about their product/research-outputs
on Common Lisp.
main framers , " how can we obtain the Common Lisp implementation ?".
My usual answer is "Ask Kyoto if you have a skill to develop your own version
and make your own Common Lisp consulting KCL,
Or Ask Lucid or CMU to buy a source codes. Lucid may give you a OEM contract.
I am not certain that Lucid will do or not.
I think CMU means Prof. Fahlman may give you a chance.
I am not certain that Prof. Fahlman will do something or not."
Merry Christmas and a happy new year !
Masayuki,
∂22-Dec-86 1552 robbins%ramona.DEC@decwrl.DEC.COM Re: FOLLOW-SYNONYM-STREAM
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 22 Dec 86 15:52:25 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA01787; Mon, 22 Dec 86 15:52:26 PST
Message-Id: <8612222352.AA01787@decwrl.dec.com>
Date: Monday, 22 Dec 1986 15:51:00-PST
From: robbins%ramona.DEC@decwrl.DEC.COM
To: Common-Lisp@SAIL.Stanford.Edu
Subject: Re: FOLLOW-SYNONYM-STREAM
We intend to include the following functions in future versions of VAX LISP:
Predicates:
synonym-stream-p
broadcast-stream-p
concatenated-stream-p
two-way-stream-p
echo-stream-p
string-stream-p
dribble-stream-p
file-stream-p
terminal-stream-p
open-stream-p
Accessors:
synonym-stream-symbol
broadcast-stream-streams
concatenated-stream-streams
two-way-stream-input-stream
two-way-stream-output-stream
echo-stream-input-stream
echo-stream-output-stream
-- Rich
∂22-Dec-86 2035 RPG Getting things rolling
∂22-Dec-86 2032 Moon@STONY-BROOK.SCRC.Symbolics.COM Getting things rolling
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Dec 86 20:32:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29908; Mon 22-Dec-86 23:30:30 EST
Date: Mon, 22 Dec 86 23:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Getting things rolling
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: gls@ZARATHUSTRA.THINK.COM, masinter.pa@XEROX.COM,
DCM%HPFCLP@HPLABS.HP.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
edsel!jonl@NAVAJO.STANFORD.EDU, rpg@SAIL.STANFORD.EDU,
Mathis@[26.6.0.103]
In-Reply-To: <FAHLMAN.12263664667.BABYL@C.CS.CMU.EDU>
Message-ID: <861222232954.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 17 Dec 1986 23:02 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
My own view is that we want to set up a sort of tree structure to handle
this....
That sounds workable. I suggest that if no individual can be found to
take responsibility for a particular issue, that there be no attempt to
construct a proposal for that issue. That way there is more of a chance
of accomplishing something lasting, even if only a subset of the imaginable
goals are achieved.
Once we've got proposals we like (or a coherent set of alternatives), I
suppose we should run these past the Common Lisp mailing list. I
suggest that we put out a big batch of proposals at once, harvest any
good ideas or useful criticisms, go back into committee, and make
modifications there. We should probably not answer every comment, get
into debates on the Common Lisp mailing list, or encourage others out
there to debate among themselves. We'll have to move very cautiously to
avoid a repeat of last summer's mail storm.
I think it's very important to run proposals past the big Common Lisp
mailing list. I don't think it makes sense to think of that as optional,
or as a painful but necessary duty. Those people out there can provide a
sanity check. Also, if enough of them don't like something it won't fly,
no matter what X3J13 says, unless the Lisp community has suddenly become
a lot more authoritarian than I think.
I think a better idea for avoiding mail storms is to let proposals out one
at a time, or a few at a time, rather than in big batches. I certainly
agree that there should be no obligation to answer every comment. Letting
the people out there debate among themselves is fine. The X3J13 process
should slow things down enough that there is no problem in waiting for
the discussion on the big mailing list, if a discussion starts, to converge
or peter out before finalizing the proposal.
...the view should be that we are drafting proposals, and that we
are occasionally asking the big mailing list to help us in drafting
those proposals.
Agreed.
∂23-Dec-86 0927 RPG minutes of Dallas meeting
∂22-Dec-86 2143 FAHLMAN@C.CS.CMU.EDU minutes of Dallas meeting
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Dec 86 21:43:02 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 23 Dec 86 00:43:28-EST
Date: Tue, 23 Dec 1986 00:43 EST
Message-ID: <FAHLMAN.12264993845.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: ida%u-tokyo.junet@RELAY.CS.NET
Cc: gls@ZARATHUSTRA.THINK.COM, mathis@ADA20.ISI.EDU, rpg@SAIL.STANFORD.EDU
Subject: minutes of Dallas meeting
In-reply-to: Msg of Mon 22 Dec 86 15:26:58+0900 from Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet at RELAY.CS.NET>
Masayuki,
Thanks for bringing us up to date on the news from Japan.
If a company wants to build their own Common Lisp, rather than paying
some company like Lucid to do the job, then KCL is probably the quickest
and easiest route. The target machine must have sufficient address space
and a good C compiler.
These companies are also welcome to use our public-domain Spice Lisp
code as the basis for an implementation, though that requires
considerably more work. There is no charge for this code, though there
is a problem in sending the code directly to a company outside the U.S.
I would have to transfer the sources to some U.S. intermediary, who
could then export the code to Japan (observing U. S. export laws).
Mr. Hagiya and Mr. Yuasa already have an older version of the Spice Lisp
sources, and our permission to distribute this code to companies in
Japan.
Merry Christmas and Happy New Year to you as well!
Scott
∂26-Dec-86 1521 RICHER@SUMEX-AIM.STANFORD.EDU CL-WINDOWS mailing list
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Dec 86 15:21:31 PST
Date: Fri 26 Dec 86 15:21:19-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: CL-WINDOWS mailing list
To: commonloops.pa@XEROX.COM, common-lisp@SAIL.STANFORD.EDU,
xpert@ATHENA.MIT.EDU
cc: news-makers@BRILLIG.UMD.EDU
Message-ID: <12265972863.15.RICHER@SUMEX-AIM.STANFORD.EDU>
As a follow-up to the enquiries I made in earlier messages regarding
people interested in Commonlisp/Commonloops window systems interfaced
to X (or News), I subsequently found out later that there is already a
mailing list called CL-WINDOWS. This list had been quiet for a long time.
It's original intention was to define a Commonlisp window standard. The
emergence of Commonloops and language independent, network-based window
systems such as X and News adds a new dimension to the discussion of a
Commonlisp window system. If you are not on the list you can get on by
sending a request to cl-windows@sail.stanford.edu.
NOTE: I do not maintain this list.
Happy New Year,
Mark
depending on the current state addressing schemes.
-------
∂29-Dec-86 1129 RICHER@SUMEX-AIM.STANFORD.EDU Re: CL-WINDOWS mailing list
Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Dec 86 11:29:08 PST
Date: Mon 29 Dec 86 11:28:50-PST
From: Mark Richer <RICHER@SUMEX-AIM.STANFORD.EDU>
Subject: Re: CL-WINDOWS mailing list
To: commonloops.pa@XEROX.COM, common-lisp@SAIL.STANFORD.EDU,
xpert@ATHENA.MIT.EDU, news-makers@BRILLIG.UMD.EDU,
RICHER@SUMEX-AIM.STANFORD.EDU, cl-windows@SAIL.STANFORD.EDU
In-Reply-To: <12265972863.15.RICHER@SUMEX-AIM.STANFORD.EDU>
Message-ID: <12266716971.39.RICHER@SUMEX-AIM.STANFORD.EDU>
I apologize to people on cl-windows for saying that you get on the list
by mailing to CL-WINDOWS@SAIL.STANFORD.EDU .... I meant to type
CL-WINDOWS-REQUEST@..... As many of you know adding -REQUEST is a convention
for mailing adminstrative requests such as getting added to a list
(so everyone doesn't have to see those messages). Sorry. This proves I
am only human afterall,
Mark
-------
∂30-Dec-86 1215 Masinter.pa@Xerox.COM courses on Common Lisp
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Dec 86 12:15:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 DEC 86 11:21:37 PST
Date: 30 Dec 86 11:21 PST
From: Masinter.pa@Xerox.COM
Subject: courses on Common Lisp
To: common-lisp@sail.stanford.edu, info-1100@sumex-aim.stanford.edu
reply-to: Masinter.pa@Xerox.COM
Message-ID: <861230-112137-301@Xerox>
I'm interested in hearing from anyone who teaches (or has taken) an
"advanced" Lisp/Common Lisp programming course in a university setting.
I'm preparing such a course and would be interested in hearing about the
course outline, topics covered, course materials, etc.
I will summarize the responses and send the summary to all who
contribute.
Larry
∂02-Jan-87 2209 MURRAY%cs.umass.edu@RELAY.CS.NET Implicit Blocks considered harmful
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Jan 87 22:09:19 PST
Received: from cs.umass.edu by csnet-relay.csnet id ag11867; 3 Jan 87 1:05 EST
Date: Fri, 2 Jan 87 15:25 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SU-AI.ARPA
Subject: Implicit Blocks considered harmful
X-VMS-To: CSNET%"common-lisp@su-ai.ARPA"
I don't see any motivation for having implicit blocks around functions,
and think they should be eliminated for the following reasons:
1) It is used very infrequently, so there is no reason to pay the overhead
in both the interpreter and when compiling one.
2) It is trivial to put one in yourself if you need it, so code that
uses them now can easily be updated (Automatically even).
3) It's a bad idea to begin with, since it couples the NAME of the
function with how it operates. Thus, if you ever change the name
you must go through and check for any return-froms.
4) Most importantly, it is a problem for parallelism. A Block cannot
return until all of its sub-forms have returned values, since one of them
can do a Return-From. This is only a problem for the interpretor
since the compiler knows if a return-from is used, but now interpreted
code and compiled code will get different behavior.
If people insist on having implicit blocks, I think the name of the
block should be T, instead of the function name.
Kelly Murray
∂03-Jan-87 1051 FAHLMAN@C.CS.CMU.EDU Implicit Blocks considered harmful
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 87 10:51:34 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 3 Jan 87 13:51:36-EST
Date: Sat, 3 Jan 1987 13:51 EST
Message-ID: <FAHLMAN.12268020905.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MURRAY%cs.umass.edu@RELAY.CS.NET
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Implicit Blocks considered harmful
In-reply-to: Msg of 2 Jan 1987 14:25-EST from MURRAY%cs.umass.edu at RELAY.CS.NET
I don't see any motivation for having implicit blocks around functions,
and think they should be eliminated for the following reasons:
1) It is used very infrequently, so there is no reason to pay the overhead
in both the interpreter and when compiling one.
I've seen this used a fair amount, and people seem to find the resulting
code very intuitive. As for overhead, it doesn't slow down compiled
code if you don't use this mechanism. There are many things in the
language that are less useful and that slow down the interpreter; in the
past, we've taken the attitude that this doesn't matter too much, though
I realize this is debatable.
2) It is trivial to put one in yourself if you need it, so code that
uses them now can easily be updated (Automatically even).
3) It's a bad idea to begin with, since it couples the NAME of the
function with how it operates. Thus, if you ever change the name
you must go through and check for any return-froms.
If you ever change the name of the function, it is trivial to check for
any return-froms (Automatically even).
4) Most importantly, it is a problem for parallelism. A Block cannot
return until all of its sub-forms have returned values, since one of them
can do a Return-From. This is only a problem for the interpretor
since the compiler knows if a return-from is used, but now interpreted
code and compiled code will get different behavior.
Common Lisp was not designed to support parallelism. Since none of us
could claim that we had a good grasp of what a parallel Lisp should look
like, we decided not to try to put in a lot of half-measures to make
various styles of parallel processing easier. That is why, for example,
we require left-to-right order of argument evaluation instead of leaving
this unspecified. People who want to play with parallel Lisp systems
will undoubtedly want to change Common Lisp in a variety of ways, and
eliminating the implicit block may be one of them, but until one of
these styles "takes hold", I don't think we should mess with the
standard language to accommodate people's hunches about what might
interfere with the style of parallelism they prefer.
-- Scott
∂05-Jan-87 0736 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Implicit Blocks considered harmful
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 5 Jan 87 07:36:39 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42361; Mon 5-Jan-87 10:27:28 EST
Date: Mon, 5 Jan 87 10:25 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Implicit Blocks considered harmful
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
MURRAY%cs.umass.edu@RELAY.CS.NET
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12268020905.BABYL@C.CS.CMU.EDU>
Message-ID: <870105102529.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Sat, 3 Jan 1987 13:51 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
3) It's a bad idea to begin with, since it couples the NAME of the
function with how it operates. Thus, if you ever change the name
you must go through and check for any return-froms.
If you ever change the name of the function, it is trivial to check for
any return-froms (Automatically even).
Indeed, it is harder to find and change the callers!
∂05-Jan-87 0759 williams%blue.decnet@ari-hq1.ARPA request list
Received: from ARI-HQ1.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jan 87 07:59:10 PST
Date: 5 Jan 87 10:52:00 EST
From: "BLUE::WILLIAMS" <williams%blue.decnet@ari-hq1.ARPA>
Subject: request list
To: "common-lisp" <common-lisp@su-ai.ARPA>
cc: williams
Reply-To: "BLUE::WILLIAMS" <williams%blue.decnet@ari-hq1.ARPA>
Please include me on the list for information.
williams@ari-hq1.arpa
thank you.
------
∂05-Jan-87 0917 RPG Cleanup committee
∂05-Jan-87 0804 FAHLMAN@C.CS.CMU.EDU Cleanup committee
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 08:04:17 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 5 Jan 87 10:56:42-EST
Date: Mon, 5 Jan 1987 10:56 EST
Message-ID: <FAHLMAN.12268513342.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: gls@ZARATHUSTRA.THINK.COM, masinter.pa@XEROX.COM,
"hpfclp!dcm"@HPLABS.HP.COM, kmp@SCRC-STONY-BROOK.ARPA,
"edsel!jonl"@NAVAJO.STANFORD.EDU, fahlman@C.CS.CMU.EDU,
moon@SCRC-STONY-BROOK.ARPA
cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: Cleanup committee
Now that we're all recovered from the holidays and ready for action,
there are several administrative points to deal with:
We seem, finally, to have made contact with Dave Matthews. Let us hope
that the H-P mailers now settle into a state of boring predictability.
Dave Moon has agreed to join this committee, with the understanding that
most of his Clisp-related time in the near future should go to the
object proposal and not to cleanup stuff. I take that to mean that he
will follow and comment on what we're doing here, but that for now he
won't be writing many proposals on cleanup stuff. I trust that the rest
of you find this acceptable?
Now that the first of the year has passed, we have only one volunteer to
be chairman (coordinator? shepherd?) of the cleanup group: Larry
Masinter. I move that we name Larry our chairman for six months, at
which time we can re-assess how well the group is functioning and
whether Larry has survived the ordeal.
I am partly done with my effort to reorganize the ISSUES list. One more
good day of work should do the trick, and I should be able to fit such a
day in soon.
-- Scott
∂06-Jan-87 0807 @ACORN.CS.ROCHESTER.EDU:miller@cs.rochester.edu maplist and lists
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 08:07:33 PST
Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 6123; Tue 6-Jan-87 11:07:53 EST
Date: Tue, 6 Jan 87 11:07 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: maplist and lists
To: common-lisp@sail.stanford.edu
cc: miller@ACORN.CS.ROCHESTER.EDU
Message-ID: <870106110759.5.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Is there a particular motivation for not having maplist work on dotted lists?
It seems to me to be well defined (and useful) to do so, but CLtL states that
functions described as taking lists as arguments only really take true lists.
For example
(maplist #'(lambda (x) x) '(a b . c))
((a b . c) (b . c) c)
I'd like to see the definition extended to require maplist to take true and
dotted lists.... This is an upward compatible extension.
Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu
miller@rochester.arpa
∂06-Jan-87 0840 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM maplist and lists
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 6 Jan 87 08:39:22 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42874; Tue 6-Jan-87 11:37:52 EST
Date: Tue, 6 Jan 87 11:35 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: maplist and lists
To: miller@cs.rochester.edu, common-lisp@sail.stanford.edu
In-Reply-To: <870106110759.5.MILLER@CASHEW.CS.ROCHESTER.EDU>
Message-ID: <870106113546.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Tue, 6 Jan 87 11:07 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Is there a particular motivation for not having maplist work on dotted lists?
It seems to me to be well defined (and useful) to do so, but CLtL states that
functions described as taking lists as arguments only really take true lists.
For example
(maplist #'(lambda (x) x) '(a b . c))
((a b . c) (b . c) c)
I'd like to see the definition extended to require maplist to take true and
dotted lists.... This is an upward compatible extension.
What do you want
(maplist #'list '(1 2 3 . 4) '(a b . c) '(x y z w q r s))
to return, and why? What I'm asking for is your "well defined"
definition.
∂06-Jan-87 0959 @ACORN.CS.ROCHESTER.EDU:miller@CS.ROCHESTER.EDU maplist and lists
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 09:57:45 PST
Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 6136; Tue 6-Jan-87 12:57:37 EST
Date: Tue, 6 Jan 87 12:57 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: maplist and lists
To: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@sail.stanford.edu, miller@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <870106113546.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Message-ID: <870106125744.1.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Date: Tue, 6 Jan 87 11:35 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Tue, 6 Jan 87 11:07 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
What do you want
(maplist #'list '(1 2 3 . 4) '(a b . c) '(x y z w q r s))
to return, and why? What I'm asking for is your "well defined"
definition.
(((1 2 3 . 4) (a b . c) (x y z w q r s))
((2 3 . 4) (b . c) (y z w q r s))
((3 . 4) c (z w q r s)))
since there are no further cdr's of the middle form that would be it!
One can argue that
w/o dotted lists one can continue to take cdrs (getting nil) until all lists
are ended, but using a dotted list, you "wave" that - one of the lists
finished, so there are no further maps to be done. Note that this is not a
problem it might be with MAPCAR, where a lot of information might be
(silently) lost, though the same principle could apply...
Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu
miller@rochester.arpa
∂06-Jan-87 1005 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM maplist and lists
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 6 Jan 87 10:05:08 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 42925; 6 Jan 87 13:03:31 EST
Date: Tue, 6 Jan 87 13:01 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: maplist and lists
To: miller@cs.rochester.edu,
David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870106125744.1.MILLER@CASHEW.CS.ROCHESTER.EDU>
Message-ID: <870106130128.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Tue, 6 Jan 87 12:57 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Date: Tue, 6 Jan 87 11:35 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Tue, 6 Jan 87 11:07 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
What do you want
(maplist #'list '(1 2 3 . 4) '(a b . c) '(x y z w q r s))
to return, and why? What I'm asking for is your "well defined"
definition.
(((1 2 3 . 4) (a b . c) (x y z w q r s))
((2 3 . 4) (b . c) (y z w q r s))
((3 . 4) c (z w q r s)))
since there are no further cdr's of the middle form that would be it!
One can argue that
w/o dotted lists one can continue to take cdrs (getting nil) until all lists
are ended, but using a dotted list, you "wave" that - one of the lists
finished, so there are no further maps to be done. Note that this is not a
problem it might be with MAPCAR, where a lot of information might be
(silently) lost, though the same principle could apply...
That's pretty much what I expected. That still doesn't give an EXACT
definition. Consider
(maplist #'identity '(1 2 3))
vs (maplist #'identity '(1 2 3 . nil))
One could argue the final "dotted" NIL should be explicitly passed, and
the result of both would be
((1 2 3) (2 3) (3) NIL)
instead of the current
((1 2 3) (2 3) (3))
∂06-Jan-87 1238 @ACORN.CS.ROCHESTER.EDU,@CASHEW.CS.ROCHESTER.EDU:miller@ACORN.CS.ROCHESTER.EDU maplist and lists
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 12:38:27 PST
Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 6148; 6 Jan 87 15:38:42 EST
Date: Tue, 6 Jan 87 15:38 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: maplist and lists
To: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
cc: common-lisp@sail.stanford.edu, miller@ACORN.CS.ROCHESTER.EDU
In-Reply-To: <870106130128.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Message-ID: <870106153848.2.MILLER@CASHEW.CS.ROCHESTER.EDU>
Sender: miller@cs.rochester.edu
Reply-To: miller@cs.rochester.edu
Organization: University of Rochester, Department of Computer Science
Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627
Phone: 716-275-7747
Date: Tue, 6 Jan 87 13:01 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Tue, 6 Jan 87 12:57 EST
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
That's pretty much what I expected. That still doesn't give an EXACT
definition. Consider
(maplist #'identity '(1 2 3))
vs (maplist #'identity '(1 2 3 . nil))
One could argue the final "dotted" NIL should be explicitly passed, and
the result of both would be
((1 2 3) (2 3) (3) NIL)
instead of the current
((1 2 3) (2 3) (3))
One could argue that, I suppose, but I don't. Since this is not a dotted list
(even if it is input that way it is still a "true" list) the current maplist
would be sufficient, and necessary to maintain compatibility.
Where this is of interest, by the way, consider a pattern matcher: (A . ?x)
is pretty regular input. (or ((A B . ?x) D ?y) for that matter...) the point
is that right now there are no DO or MAP forms that can handle this dotted
form in a trivial way. And, I don't see any particular reason why they
shouldn't. (This may just be shortsightedness on my part...)
Brad Miller
------
miller@cs.rochester.edu
miller@acorn.cs.rochester.edu
miller@rochester.arpa
∂06-Jan-87 1555 tsf@theory.cs.cmu.edu Destructive operations
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 15:55:19 PST
Date: Tuesday, 6 January 1987 18:55:49 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: common-lisp@sail.stanford.edu
cc: gross@sam.cs.cmu.edu
Subject: Destructive operations
Message-ID: <1987.1.6.23.36.41.Timothy.Freeman@theory.cs.cmu.edu>
I have been using a lisp compiler which gets an access violation at
the last statement of the following scenario:
(defun foo () '(1 2))
(compile 'foo)
;; Save a core image to disk
;; Run the saved core image
(setf (cdr (foo)) 3)
;; The above statement bombs
This behavior seems reasonable, and I understand why it is happening.
My questions are:
If you omit saving and restoring the core image, does this behavior
fit the specification?
Is the specification too vague about this?
My opinion is that it should be permissable for the code to bomb in
cases like this.
Tim Freeman
∂06-Jan-87 1629 FAHLMAN@C.CS.CMU.EDU Destructive operations
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 16:29:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 6 Jan 87 19:29:33-EST
Date: Tue, 6 Jan 1987 19:29 EST
Message-ID: <FAHLMAN.12268868858.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Timothy.Freeman@THEORY.CS.CMU.EDU
Cc: common-lisp@SAIL.STANFORD.EDU, gross@SAM.CS.CMU.EDU
Subject: Destructive operations
In-reply-to: Msg of 6 Jan 1987 18:55-EST from Timothy.Freeman at theory.cs.cmu.edu
In my view, when a constant appears in code, the compiler is free to
store this in read-only space or do other strange things that depend on
the constantness of the constant. Many useful optimizaitons depend on
this. I thought that I could find something in the manual that implied
this clearly, but a cursory search failed. The description of
DEFCONSTANT says that the compiler assume that such constants will stay
put, but I found nothing about other constants, such as '(a b c), that
might appear in the body of the code. Still, I think that we must allow
the compiler to assume that these things will not be altered
destructively. You can always store the list in a variable if you want
it to be malleable.
CLtL doesn't say much about what the compiler is required to do or not
do. A subcommittee of X3J13 has been set up to formulate
recommendations on how to fix this. This is one of the issues that they
should address.
-- Scott
∂06-Jan-87 1738 edsel!babel!eb@navajo.stanford.edu Destructive operations
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 17:38:06 PST
Received: by navajo.stanford.edu; Tue, 6 Jan 87 17:37:22 PST
Received: from blacksox.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01137; Tue, 6 Jan 87 16:49:47 pst
Received: by blacksox.edsel.uucp (4.12/9.2)
id AA00286; Tue, 6 Jan 87 16:49:13 pst
Date: Tue, 6 Jan 87 16:49:13 pst
From: edsel!babel!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8701070049.AA00286@blacksox.edsel.uucp>
To: navajo!Timothy.Freeman%theory.cs.cmu.edu@navajo.stanford.edu
Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: navajo!Timothy.Freeman@theory.cs.cmu.edu's message of Tuesday, 6 January 1987 18:55:49 EST
Subject: Destructive operations
On p.78 of CLtL, in the description of the function EQ, is the
following paragraph:
``An additional problem with EQ is that the implementation is permitted
to "collapse" constants (or portions thereof) appearing in code to be
compiled if they are EQUAL. An object is considered to be a constant
in code to be compiled if it is a self-evaluating form or is contained
in a QUOTE form. This is why (EQ "Foo" "Foo") might be true or false;
in interpreted code it would normally be false, because reading in the
form (EQ "Foo" "Foo") would construct distinct strings for the two
arguments to EQ, but the compiler might choose to use the same
identical string or two distinct copies as the two arguments in the
call to EQ. Similarly, (EQ '(A . B) '(A . B)) might be true or false,
depending on whether the constant conses appearing in the QUOTE forms
were collapsed by the compiler. However, (EQ (CONS 'A 'B) (CONS 'A
'B)) is always false, because every distinct call to the CONS function
necessarily produces a new and distinct cons.''
Because the compiler is permitted to share structure with constants in
compiled code, it follows that modifying such a constant is illegal.
Some systems place such constants in a read-only region of memory.
∂07-Jan-87 0802 jrg@spice.cs.cmu.edu mailin{ list requests
Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87 08:02:22 PST
Date: Wednesday, 7 January 1987 11:02:14 EST
From: Joseph.Ginder@spice.cs.cmu.edu
To: common-lisp@sail.stanford.edu
Subject: mailin{ list requests
Message-ID: <1987.1.7.15.59.57.Joseph.Ginder@spice.cs.cmu.edu>
For the record, where should one send mailing list requests for the
general common lisp mailing list and the various sub-lists?
--Joe Ginder
∂07-Jan-87 0840 tsf@theory.cs.cmu.edu Re: Destructive operations
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87 08:39:56 PST
Date: Wednesday, 7 January 1987 11:37:53 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: edsel!babel!eb@navajo.stanford.edu (Eric Benson)
cc: common-lisp@sail.stanford.edu, gross@sam.cs.cmu.edu
Subject: Re: Destructive operations
Message-ID: <1987.1.7.16.26.12.Timothy.Freeman@theory.cs.cmu.edu>
In-Reply-To: <8701070049.AA00286@blacksox.edsel.uucp>
Because the compiler is permitted to share structure with constants in
compiled code, it follows that modifying such a constant is illegal.
Pardon me for being thick-headed, but I just don't see why this is
true. I would be willing to say that "Because the compiler is
permitted to share structure with constants in compiled code,
modifying such a constant destructively may have the side effect of
modifying any or all other constants which are equal to the given
constant". This would allow one to conclude that modifying such a
constant is a bad idea, but not that it is illegal.
I agree that it ought to be illegal, but I don't see how CLtL implies
that it is illegal.
∂07-Jan-87 1130 RPG A Happy New Year
∂06-Jan-87 1815 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET A Happy New Year
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Jan 87 18:15:42 PST
Received: from utokyo-relay by csnet-relay.csnet id ad01557; 6 Jan 87 20:51 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA08885; Wed, 7 Jan 87 10:31:16+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA20821; Wed, 7 Jan 87 10:19:02+0900
Date: Wed, 7 Jan 87 10:19:02+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8701070119.AA20821@ccut.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: A Happy New Year
Dear Sirs,
A happy new year.
We woke up and returned to the desks.
In this year, the following things will happen in japan (?)
(1) JIS group finally decide what to do.
(2) Kanji (long-character) related draft goes on.
(3) More comercial CL implementations available.
(4) Object oriented facilities for CL are popular.
(5) CL/Core get the formality.
(6) Other things which only God knows.
and,
(7) play a role for the international affairs.
No.7 is the most difficult. Japan is located at the one node of the trinity
of Asia, Europe and USA, and is one small country and have an oriental calture.
I will continue to keep communication good between Japan and US
(and Europe though we could not make a frank communication with them last year).
I want to attend the next X3J13 meeting.
And I am ready to talk.
Thank you.
Masayuki Ida
∂07-Jan-87 1221 edsel!babel!eb@navajo.stanford.edu Destructive operations
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jan 87 12:21:34 PST
Received: by navajo.stanford.edu; Wed, 7 Jan 87 12:20:41 PST
Received: from blacksox.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA02629; Wed, 7 Jan 87 11:38:55 pst
Received: by blacksox.edsel.uucp (4.12/9.2)
id AA00348; Wed, 7 Jan 87 11:38:23 pst
Date: Wed, 7 Jan 87 11:38:23 pst
From: edsel!babel!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8701071938.AA00348@blacksox.edsel.uucp>
To: navajo!Timothy.Freeman%theory.cs.cmu.edu@navajo.stanford.edu
Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu,
navajo!gross%sam.cs.cmu.edu@navajo.stanford.edu
In-Reply-To: navajo!Timothy.Freeman@theory.cs.cmu.edu's message of Wednesday, 7 January 1987 11:37:53 EST
Subject: Destructive operations
Right you are. I was assuming too much. Just because something may
have horrible consequences doesn't necessarily make it illegal.
Modifying constants in compiled code has the same legal status as
modifying the SYMBOL-NAME string of a symbol. ``It is an extremely
bad idea to modify'' a constant in compiled code. ``Such a
modification may tremendously confuse'' any function which contains a
constant EQUAL to the one being modified. For similar reasons, it is
a bad idea to modify any object which is used as a key in an EQUAL
hash table (this problem is unfortunately not mentioned in CLtL).
∂09-Jan-87 0944 SAM@XX.LCS.MIT.EDU Recursive COMPILE-FILE?
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jan 87 09:44:15 PST
Date: Fri 9 Jan 87 12:44:09-EST
From: Stuart A. Malone <SAM@XX.LCS.MIT.EDU>
Subject: Recursive COMPILE-FILE?
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12269581500.45.SAM@XX.LCS.MIT.EDU>
Is a Common Lisp compiler required to correctly handle forms such as:
(eval-when (compile)
(compile-file "utils"))
I am working with two different implementations of Common Lisp that ignore
inline declarations unless the functions being placed inline are compiled, so
guaranteeing that the inline "utils" file is always compiled before the main
file is useful.
May I scream at the compiler implementors to make this work?
--Stuart A. Malone
-------
∂09-Jan-87 0954 Moon@STONY-BROOK.SCRC.Symbolics.COM Recursive COMPILE-FILE?
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jan 87 09:54:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 39867; Fri 9-Jan-87 12:54:18 EST
Date: Fri, 9 Jan 87 12:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Recursive COMPILE-FILE?
To: Stuart A. Malone <SAM@XX.LCS.MIT.EDU>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <12269581500.45.SAM@XX.LCS.MIT.EDU>
Message-ID: <870109125312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri 9 Jan 87 12:44:09-EST
From: Stuart A. Malone <SAM@XX.LCS.MIT.EDU>
Is a Common Lisp compiler required to correctly handle forms such as:
(eval-when (compile)
(compile-file "utils"))
I think you need to define "correctly handle" a little more explicitly.
The form you have written says: if this form is encountered at top level
by the compiler, compile another file, do nothing with the results of
the compilation, and then resume the original compilation. Aside from
the creation of a compiler output file in the file system, the only
effect of this would be to make the compilation take longer. I assume
you really intended for something else to happen?
∂09-Jan-87 1001 FAHLMAN@C.CS.CMU.EDU Recursive COMPILE-FILE?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Jan 87 10:00:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 9 Jan 87 12:59:06-EST
Date: Fri, 9 Jan 1987 12:58 EST
Message-ID: <FAHLMAN.12269584200.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "Stuart A. Malone" <SAM@XX.LCS.MIT.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Recursive COMPILE-FILE?
Is a Common Lisp compiler required to correctly handle forms such as:
(eval-when (compile)
(compile-file "utils"))
I don't think that there's anything in the current spec that requires
COMPILE-FILE to be re-entrant, and at least a couple of implementations
would have a hard time doing this because of the way they store the
compilation environment. Obviously it is better for all concerned if
something like this does work in your favorite implementation, but I
don't think it is required.
There is now a subcommittee under X3J13 that is studying the whole
question of tightening up the compiler specifications. It will be up to
them to weigh the costs and benefits of requiring this change and to
make a recommendation to X3J13. I'm sure at some point they will be
seeking the community's input on such issues.
-- Scott
∂09-Jan-87 1027 RPG Issues file
∂08-Jan-87 2142 FAHLMAN@C.CS.CMU.EDU Issues file
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jan 87 21:42:32 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 9 Jan 87 00:39:52-EST
Date: Fri, 9 Jan 1987 00:39 EST
Message-ID: <FAHLMAN.12269449630.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: gls@ZARATHUSTRA.THINK.COM, masinter.pa@XEROX.COM,
hpfclp!dcm@HPLABS.HP.COM, kmp@SCRC-STONY-BROOK.ARPA,
"edsel!jonl"@NAVAJO.STANFORD.EDU, fahlman@C.CS.CMU.EDU,
moon@SCRC-STONY-BROOK.ARPA
cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: Issues file
[Mail to Dave Matthews still seems to be bouncing most of the time.
Sigh! Maybe H-P should break down and buy a Vax to handle mail. I
don't think you can buy Dec-20's these days.]
I have reorganized the old ISSUES.TXT file and cleaned it up some. It
may prove useful as an inventory of the things we ought to work on.
This file is on C.CS.CMU.EDU in PRVA:<SLISP.STANDARD>ISSUES.TXT. It
should be FTP'able from there. If you have trouble, let me know and
I'll mail you a copy.
I have not added any issues raised since last summer's Lisp Conference.
I have included the formal proposals from last summer in this file in
stripped-down form, more or less as place-holders. I have not yet tried
to sift through all that mail to find all of the options and amendments
that people proposed in discussing these proposals.
It think that it would be encouraging to everyone if we could come up
with specific proposals on a bunch of easy, obvious clarifications in
time for the next meeting, if we can find some easy ones. We also
should at least come up with a plan of action for the harder issues.
I take your silence on the issue of chairmanship as assent. I now
resign my temporary leadership of this committee to Larry Masinter. As
chairman, it will be up to him to manage the discussions from this
point. Of course, I will continue to do some of the work on various
technical issues.
-- Scott
∂09-Jan-87 1234 SAM@XX.LCS.MIT.EDU Recursive COMPILE-FILE?
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jan 87 12:34:47 PST
Date: Fri 9 Jan 87 15:34:22-EST
From: Stuart A. Malone <SAM@XX.LCS.MIT.EDU>
Subject: Recursive COMPILE-FILE?
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <870109125312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <12269612486.14.SAM@XX.LCS.MIT.EDU>
Is a Common Lisp compiler required to correctly handle forms such as:
(eval-when (compile)
(compile-file "utils"))
I think you need to define "correctly handle" a little more explicitly.
--------
I'm sorry if I wasn't clear. I usually follow such a form with a form like:
(eval-when (compile)
(load "utils"))
This pair of forms produces a useful result in the implementations I am using,
because it assures (in these implementations) that functions I have declared
inline will actually be coded inline. By "correctly handle" I meant that the
file "utils" should be compiled (producing a side-effect on the file system)
and that the compilation of the main file should continue without error. I
didn't think that whether or not I decided to load the resulting fasload file
had any bearing on the question.
--Stuart
-------
∂09-Jan-87 1747 RPG Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
∂09-Jan-87 1513 Masinter.pa@Xerox.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jan 87 15:11:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 87 14:28:08 PST
Date: 9 Jan 87 14:28 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
To: Fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
masinter.pa@Xerox.COM, hpfclp!dcm@HPLABS.HP.COM,
kmp@SCRC-STONY-BROOK.SYMBOLICS.COM, "edsel!jonl"@NAVAJO.STANFORD.EDU,
moon@SCRC-STONY-BROOK.SYMBOLICS.COM, rpg@SAIL.STANFORD.EDU,
Mathis@ADA20.ISI.EDU
reply-to: Masinter.PA@Xerox.COM
Message-ID: <870109-142808-3303@Xerox>
(Note: this is a sample of the format I had in mind.)
Please reply if you
a) agree with the analysis and vote for adopting the proposal
b) disagree with the analysis; if so, please explain briefly
c) have an alternative proposal
Issue: (Steele, p. 106) If a macro that performs similar processing to
SETF uses GET-SETF-METHOD, and that macro occurs within a MACROLET, the
expansion will not see the MACROLET definition, e.g.
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Classification: This is a mistake in CLtL.
Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to GET-SETF-METHOD. If the argument
is not supplied, you get the null lexical environment.
Allow DEFINE-SETF-METHOD to take an ENVIRONMENT argument.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Rationale:
a) this codifies existing practice: many Common Lisp implementations
already have adopted this change.
b) the cost of adopting this change is small but non-zero: some
implementations must change their definitions.
c) the cost of converting existing code is zero, since this is an upward
compatible change. However, implementations which did not already take
into account the lexical environment for SETF'd forms might start
working differently if the internal implementation of SETF is changed.
d) this is an upward compatible change, so that the staging is simple.
Other aesthetic critera:
Adding environment arguments to get-setf-method complicates it and its
callers. An alternative, removing MACROLET, would result in a simpler
language. If the rest of the language were changed so that there were no
differences between the interpretation of setfs in any lexical context,
the environment argument would be extraneous.)
∂09-Jan-87 2130 RPG Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
∂09-Jan-87 1744 Masinter.pa@Xerox.COM Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jan 87 17:44:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 87 17:43:41 PST
Date: 9 Jan 87 17:43 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
To: Fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
masinter.pa@Xerox-COM.ARPA, hpfclp!dcm@HPLABS.HP.COM,
kmp@SCRC-STONY-BROOK.SYMBOLICS.COM, edsel!jonl@NAVAJO.STANFORD.EDU,
moon@SCRC-STONY-BROOK.SYMBOLICS.COM, rpg@SAIL.STANFORD.EDU,
Mathis@ADA20.ISI.EDU
reply-to: Masinter.PA@Xerox.COM
Message-ID: <870109-174341-3517@Xerox>
(I am not sure I realized how big this "issues" file was! However, it
seems useful to have the examples placed in the paperwork we present to
X3j13 so we don't have to go through the justifications again.)
Please reply if you
a) agree with the analysis and vote for adopting the proposal
b) disagree with the analysis; if so, please explain briefly
c) have an alternative proposal
Issue: (Steele, p. 144) The macro function associated with a given
symbol depends on the lexical context of that symbol, and can differ
inside a MACROLET (which introduces lexical macros), or inside a FLET or
LABELS (which shadow macros). However, there is no way to account for
this lexical context in macros which know their environment (using the
&ENVIRONMENT argument) and which do their own macro expansion.
Example:
(defmacro example (form &environment environment)
(let ((macro (macro-function (car form)))
(when macro .... (funcall macro form) ...)
Normally, the macro-function definition reflects the interpretation of
the FORM argument to EXAMPLE. However, within a MACROLET it does not.
Classification: This is a mistake in CLtL.
Proposal MACRO-FUNCTION-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to MACRO-FUNCTION. If the argument
is not supplied, you get the null lexical environment. Otherwise, the
environment argument is used to determine the macro definition.
The example above could then be coded:
(defmacro example (form &environment environment)
(let ((macro (macro-function (car form) environment))
(when macro .... (funcall macro form) ...)
Rationale:
a) this codifies existing practice: many Common Lisp implementations
already have adopted this change.
b) the cost of adopting this change is small but non-zero: some
implementations must change their definitions.
c) the cost of converting existing code is zero, since this is an upward
compatible change.
d) this is an upward compatible change, so that the staging is simple.
Other aesthetic critera:
Adding an environment argument to MACRO-FUNCTION complicates it and its
callers. An alternative, removing MACROLET, would result in a simpler
language. If the rest of the language were changed so that there were no
differences between the interpretation of macros in any lexical context,
the environment argument would be extraneous.
∂09-Jan-87 2130 RPG Issue: IMPORT-UNCLEAR, Message 1
∂09-Jan-87 1855 Masinter.pa@Xerox.COM Issue: IMPORT-UNCLEAR, Message 1
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jan 87 18:55:28 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 87 17:58:08 PST
Date: 9 Jan 87 17:58 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: IMPORT-UNCLEAR, Message 1
To: Fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
masinter.pa@Xerox.COM, hpfclp!dcm@HPLABS.HP.COM,
kmp@SCRC-STONY-BROOK.SYMBOLICS.COM, edsel!jonl@NAVAJO.STANFORD.EDU,
moon@SCRC-STONY-BROOK.SYMBOLICS.COM, rpg@SAIL.STANFORD.EDU,
Mathis@ADA20.ISI.EDU
reply-to: Masinter.PA@Xerox.COM
Message-ID: <870109-175808-3535@Xerox>
(This is the last one I will send out until I get some replies. I had
some trouble with elaborating this one, which I think means that I don't
understand the issue. )
Reference: Steele p. 186.
Issue: The action of IMPORT on the home package of a symbol is not
described well, as it affects the "home package" of a symbol.
Classification: clarification.
Proposal IMPORT-UNCLEAR:REWRITE:
Change the description of IMPORT to say: "if any symbol to be imported
has no home package, then IMPORT sets the home package of the symbol to
the specified package being imported to."
Clarify that INTERN does not modify a symbol's home package. Rewrite
the section avoiding the verb "intern", as it confuses everyone.
Rationale:
a) this codifies existing practice: all Common Lisp implementations work
this way.
b) the cost of adopting this change is small: it requires rewriting the
section.
c) the cost of not adopting the change is continued confusion about how
Common Lisp works, and the risks that some new implementations will not
work this way.
d) the cost of converting existing code is zero; this is just a rewrite.
∂10-Jan-87 0914 JAR@AI.AI.MIT.EDU Recursive COMPILE-FILE?
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Jan 87 09:14:26 PST
Date: Sat, 10 Jan 87 12:17:33 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Recursive COMPILE-FILE?
To: SAM@XX.LCS.MIT.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-reply-to: Msg of Fri 9 Jan 87 12:44:09-EST from Stuart A. Malone <SAM at XX.LCS.MIT.EDU>
Message-ID: <138659.870110.JAR@AI.AI.MIT.EDU>
This issue was discussed, briefly, sometime in the past year or two. As
I remember, I said something similar to the following at that time, and
got no response:
There's nothing in CLtL that would suggest that there is any context in
which it would be an error to call COMPILE-FILE. It should no more be
an error to call COMPILE-FILE from a macro expander or EVAL-WHEN form
than it would be an error to call CAR or OPEN.
I can think of no reasonable excuse for a compiler implementor to
suggest that COMPILE-FILE should not be re-entrant. So I would say that
you are permitted to complain when it is not.
Jonathan
∂10-Jan-87 1123 RPG Mailing List
To: cl-cleanup@SAIL.STANFORD.EDU
There is now a mailing list at SAIL called CL-CLEANUP (capitalization
as you wish). Mail to this list will be archived in the Common Lisp
archives.
-rpg-
∂10-Jan-87 1246 FAHLMAN@C.CS.CMU.EDU Discussion strategy
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jan 87 12:45:51 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 10 Jan 87 15:46:11-EST
Date: Sat, 10 Jan 1987 15:46 EST
Message-ID: <FAHLMAN.12269876769.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Discussion strategy
One meta-issue we need to think about is how we want to handle these
discussion vis-a-vis the Common Lisp mailing list. It is important to
run all of our proposals by the larger community before anythign is cast
in concrete, as a sort of sanity check and in order to prevent the
perception that a closed cabal is at work. On the other hand, we won't
make any progress if we wait around for the larger list to converge on
every issue.
I would suggest that we follow something like the following strategy:
1. We formulate, discuss, and initially debug proposals just among
ourselves.
2. Once we've got a batch of proposals in what we think is good shape,
we send them to Common Lisp for comment. We should listen for good
ideas and useful suggestions from "out there", but we should not feel
that we have to answer every comment that goes by. We should, of
course, pay special attention to any comments of the form "this will
screw my company/implementaiton for the following reason..."
3. After a decent interval, we ask ourselves (on the cleanup mailing
list) whether we heard anything that makes us want to modify the
proposals. If such modifications are extensive, we may decide to send
the new proposal back to the big list for further comment.
4. Once proposals have passed through the above process, we send them to
X3J13 in batches. We should bear in mind that there is a whole formal
set of checks and balances that starts at this time -- steps 1 - 3
should be viewed as merely a way of producing well-debugged proposals as
input to the formal decision process.
-- Scott
∂10-Jan-87 1520 @MCC.COM:sierchio@mcc.com Bugs in Common LISPcraft
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 10 Jan 87 15:20:40 PST
Received: from milano.sw.mcc.com by MCC.COM with TCP; Sat 10 Jan 87 17:20:54-CST
Received: from tachyon (tachyon.ARPA) by milano.sw.mcc.com (4.12/STP)
id AA28284; Sat, 10 Jan 87 17:20:44 cst
Date: Sat, 10 Jan 87 17:20:52 CST
From: Michael Sierchio <sierchio@mcc.com>
Posted-Date: Sat, 10 Jan 87 17:20:52 CST
Message-Id: <8701102320.AA00756@tachyon>
Received: by tachyon (1.1/STP)
id AA00756; Sat, 10 Jan 87 17:20:52 CST
Subject: Bugs in Common LISPcraft
Newsgroups: comp.lang.lisp,fa.clisp
Distribution: net
To: Common-Lisp@SU-AI.Arpa
Keywords: Confusion and the Like
I just wanted to point out some errors in the book Common LISPcraft
by Robert Wilensky (Norton 1986).
The book is entirely praiseworthy in its exposition of Common Lisp,
both for beginners and pros in other Lisp dialects. However, there
are two errors that I have spotted that might make it difficult for
novices to understand a few basic points.
On page 75, there is a sample function, and commentary beneath it.
The 4th text paragraph refers to a conditional test "(null ll)".
The expression in the function definition actually reads "(atom ll)".
This is the intended statement, by the way. It's the text that's wrong.
(atom ll) will, of course, return t if ll is an empty list.
On page 153, there is a sample expression describing the use of "(let ..)".
It reads:
(let ((temp (func1 x y z))
(func2 temp)
(func3 temp))
There's a paren missing, which is a normal occurance in Lisping -- however,
since this means incorrect syntax, and is likely to confuse the poor
reader, it is worth noting as an error. It should read:
(let ((temp (func1 x y z)))
(func2 temp) ↑
(func3 temp)) |
(the missing paren)
There are other typos, but none that a reader of English should have
trouble with.
This is not meant to be a complete list of errors. I will post any
other major ones that I find. Someone at Cal Berkeley could do me
the favor of pointing this out to Wilensky.
(tell Norton and anyone who's listening that I'm available for
editing any or all computer books!)
--
Michael Sierchio @ MCC Software Technology Program
UUCP: ut-sally!im4u!milano!sierchio
ARPA: sierchio@mcc.ARPA
"WE REVERSE THE RIGHT TO SERVE REFUSE TO ANYONE"
∂10-Jan-87 1633 masinter.pa@Xerox.COM Re: Discussion strategy
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Jan 87 16:33:35 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 10 JAN 87 15:28:25 PST
From: masinter.pa@Xerox.COM
Date: 10 Jan 87 15:26:00 PST
Subject: Re: Discussion strategy
In-reply-to: FAHLMAN@C.CS.CMU.EDU's message of Sat, 10 Jan 87 15:46 EST,
<FAHLMAN.12269876769.BABYL@C.CS.CMU.EDU>
To: FAHLMAN@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870110-152825-3903@Xerox>
I agree with your suggestion in the main.
For those proposals that were already discussed (in some cases ad
naseum) on the Common-Lisp@su-ai mailing list, I'm reluctant to re-open
the discussion.
I think it is important for the credibility of this committee that we
get something, no matter how small, into the official pipeline, just to
demonstrate that X3j13 actually can adopt some change to Common Lisp and
have it stick. (Maybe I'm a pessimist...)
I believe that in order for there to be a formal vote at the next X3J13
meeting, we have to have something ready to mail out by February 4,
which is only a few weeks away.
Once we get the process down, we can probably speed it up. In the
meanwhile, can we reach some consensus on the issues I've mailed out so
far?
∂11-Jan-87 0004 CMP.LADAI@R20.UTEXAS.EDU Common Classes Bboard?
Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 00:04:24 PST
Date: Sun 11 Jan 87 02:05:19-CST
From: CMP.LADAI@R20.UTEXAS.EDU
Subject: Common Classes Bboard?
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12270000413.37.CMP.LADAI@R20.UTEXAS.EDU>
Is there a Bboard or Mailing List or anything else where I can
listen in on discussions or progress on the proposed CL object-
oriented extension, Common Classes?
-------
∂11-Jan-87 1136 RPG Issues file
∂08-Jan-87 2142 FAHLMAN@C.CS.CMU.EDU Issues file
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jan 87 21:42:32 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 9 Jan 87 00:39:52-EST
Date: Fri, 9 Jan 1987 00:39 EST
Message-ID: <FAHLMAN.12269449630.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: gls@ZARATHUSTRA.THINK.COM, masinter.pa@XEROX.COM,
hpfclp!dcm@HPLABS.HP.COM, kmp@SCRC-STONY-BROOK.ARPA,
"edsel!jonl"@NAVAJO.STANFORD.EDU, fahlman@C.CS.CMU.EDU,
moon@SCRC-STONY-BROOK.ARPA
cc: rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
Subject: Issues file
[Mail to Dave Matthews still seems to be bouncing most of the time.
Sigh! Maybe H-P should break down and buy a Vax to handle mail. I
don't think you can buy Dec-20's these days.]
I have reorganized the old ISSUES.TXT file and cleaned it up some. It
may prove useful as an inventory of the things we ought to work on.
This file is on C.CS.CMU.EDU in PRVA:<SLISP.STANDARD>ISSUES.TXT. It
should be FTP'able from there. If you have trouble, let me know and
I'll mail you a copy.
I have not added any issues raised since last summer's Lisp Conference.
I have included the formal proposals from last summer in this file in
stripped-down form, more or less as place-holders. I have not yet tried
to sift through all that mail to find all of the options and amendments
that people proposed in discussing these proposals.
It think that it would be encouraging to everyone if we could come up
with specific proposals on a bunch of easy, obvious clarifications in
time for the next meeting, if we can find some easy ones. We also
should at least come up with a plan of action for the harder issues.
I take your silence on the issue of chairmanship as assent. I now
resign my temporary leadership of this committee to Larry Masinter. As
chairman, it will be up to him to manage the discussions from this
point. Of course, I will continue to do some of the work on various
technical issues.
-- Scott
∂11-Jan-87 1138 RPG Re: Issues file
∂09-Jan-87 1510 Masinter.pa@Xerox.COM Re: Issues file
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jan 87 15:10:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 87 13:48:39 PST
Date: 9 Jan 87 13:48 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issues file
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
9 Jan 87 00:39 EST
To: Fahlman@C.CS.CMU.EDU
cc: gls@ZARATHUSTRA.THINK.COM, masinter.pa@Xerox.COM,
hpfclp!dcm@HPLABS.HP.COM, kmp@SCRC-STONY-BROOK.SYMBOLICS.COM,
"edsel!jonl"@NAVAJO.STANFORD.EDU, moon@SCRC-STONY-BROOK.SYMBOLICS.COM,
rpg@SAIL.STANFORD.EDU, Mathis@ADA20.ISI.EDU
reply-to: Masinter.pa@Xerox.COM
Message-ID: <870109-134839-3244@Xerox>
I will try to get a distribution list created soon.
My notion is that it will be easier to get consensus on each of these if
we can relate the proposals we adopt to the charter of the group, viz:
* This issue is a mistake, ambiguity of minor ommission in Common Lisp:
the Language
* It is not being addressed by another group (the most serious
interactions in the proposals so far are those that might belong to the
'semantics of compilation' group)
and, where relevant:
* this codifies existing practice, facilitates portability of code, or
establishes normative programming practice
* the cost of adopting the change
* the cost of not-adopting the change
* the cost of conversion of existing code
* a "ramp-up" mechanism for introducing the change
* other aesthetic critera
I will broadcast the issues one at a time with alternatives. I will
generate a unique ID for each issue (e.g., CLARIFY-FUNCTION-DECLARATION)
& proposal (e.g., CLARIFY-FUNCTION-DECLARATION-1). Please use the ID in
the subject of your message.
I'd like to sort the issues by how quickly I think we can reach
consensus on them; does anyone prefer a different order?
I'd like to at least ask the "compiler" committee if they would take on
the ones that had to do with declarations (e.g., the function/ftype
declarations.) Does anyone think that we should tackle them first
without asking them?
∂11-Jan-87 1449 RWK@YUKON.SCRC.Symbolics.COM Recursive COMPILE-FILE?
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 11 Jan 87 14:49:34 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 146821; Sun 11-Jan-87 17:36:14 EST
Date: Sun, 11 Jan 87 17:36 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Recursive COMPILE-FILE?
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Stuart A. Malone <SAM@XX.LCS.MIT.EDU>, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12269584200.BABYL@C.CS.CMU.EDU>
Message-ID: <870111173656.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Fri, 9 Jan 1987 12:58 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Is a Common Lisp compiler required to correctly handle forms such as:
(eval-when (compile)
(compile-file "utils"))
I don't think that there's anything in the current spec that requires
COMPILE-FILE to be re-entrant,
There's nothing in the current spec that requires
FUNCALL, or MAP, or MAPHASH to be re-entrant, either.
I don't think the default assumption should be that
things only work in specific documented cases. I
think it should be assumed that they work unless
there are specific documented exceptions.
and at least a couple of implementations
would have a hard time doing this because of the way they store the
compilation environment.
I can't believe it would be hard to fix any such
broken implementations. In the worst case I can
imagine, you'd have to do a global query-replace
on GET to use a COMPILER-TABLE-GET macro that
expanded into a GETHASH or GETF as appropriate.
You'd probably get a big paging-performance
improvment in the process.
∂11-Jan-87 1904 FAHLMAN@C.CS.CMU.EDU Format of proposals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 19:04:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 11 Jan 87 22:04:50-EST
Date: Sun, 11 Jan 1987 22:04 EST
Message-ID: <FAHLMAN.12270207847.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Format of proposals
Before I comment on Larry's first three proposals, I have a couple of
minor points on the format.
First, I think it would be a good idea to very cleanly separate the
proposal itself from all the rationale. It is the proposal that we are
voting on and asking X3J13 to adopt. The rationale is important in
focusing the subsequent discussion, but it fundamentally different from
the proposal itself. It is not the sort of thing where we have to get
every word right and then chisel the result into stone forever. I'd go
so far as to put the proposal itself first, then some sort of very clear
barrier (line of *'s or whatever), then all the rationale.
Second, I'm wondering what Larry intends by the message numbers he
includes in the message headers. If I respond to his first proposal,
should I say "Re: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 2" ? That
won't work -- I'll forget to do it, and things will get screwed up if
several of us send messages that cross in the mail.
I'd suggest that each revision to a specific proposal be given a number,
so that we can refer to "GET-SETF-METHOD-ENVIRONMENT, version 3245" or
whatever, but if we want to refer to messages themselves, something like
"Moon's mail of 1/11/86, 23:30" should do the job.
-- Scott
∂11-Jan-87 1923 tsf@theory.cs.cmu.edu Packages & Compiling
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 19:22:56 PST
Date: Sunday, 11 January 1987 22:22:19 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: common-lisp@sail.stanford.edu
cc: edsel!bhopal!jonl@navajo.stanford.edu, thomas.gross@sam.cs.cmu.edu
Subject: Packages & Compiling
Message-ID: <1987.1.12.2.10.27.Timothy.Freeman@theory.cs.cmu.edu>
Jon L. White from Lucid said in a mail message to me (among other people):
Indeed, the most prevalent "obscurity" in the compilation process that
snares many users is the requirement that the package world be EXACTLY
the same at load time that it was at compile time. The act of compiling
a file with calls to IMPORT in it changes the package world structure; and
so does loading such a file (or indeed, any file with calls to IMPORT,
EXPORT, IN-PACKAGE, USE-PACKAGE, INTERN, etc in it).
He isn't clear about whether he is claiming this for Lucid
Common Lisp only or for all common lisps anywhere. He didn't give me
permission to repeat his words to a mailing list, so please don't
crucify him if what he said is wrong.
Since most of the lisp I write lives in its own package, most of my
source files have calls to import & such. Thus, if I took his statement
seriously, I would hardly ever be able to compile the same file twice
in the same lisp image and expect the same results from the
compilations, because the first compilation's calls to import would
cause the second compilation to have a different package environment.
CLtL specifies the compiler by saying that "compiling a file of code
should produce an equivalent but more efficient program". Jon is
saying "compiling a file of code should produce an equivalent but more
efficient program, provided that the package environment at compile
time is the same as the package environment at load time; otherwise
all bets are off". I can imagine ways of implementing compilers so
that the qualifier about the package environment is unneccessary.
(I'll elaborate my imagination if it becomes apparent that people
don't believe me.)
Should Jon's statement be true of the common lisp standard? If so,
why is doing it that way better than avoiding the repeated compilation
problem that is described above?
∂11-Jan-87 1936 FAHLMAN@C.CS.CMU.EDU A comment on MACROLET...
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 19:36:41 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 11 Jan 87 22:36:58-EST
Date: Sun, 11 Jan 1987 22:36 EST
Message-ID: <FAHLMAN.12270213698.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: A comment on MACROLET...
In the issues file, it is pointed out in several places that the
"environment arg" issues would go away if we were to flush MACROLET.
Every time I start wrestling with explicit environment passing, I get
disgusted and start regretting that we ever let MACROLET in. That is
the source of these comments.
Masinter has pointed out that if we allow FLET and LABELS to shadow
macro definitions with function definitions, then various
macro-expanding forms will need to get at the environment even if
MACROLET goes away. So flushing MACROLET is not a solution, and clearly
there is no chance of flushing FLET and LABELS at this point.
We could, I suppose, forbid FLET and LABELS to shadow existing macros,
but that is even more of a crock than passing around environment
arguments. So unless someone can see a clever way out of this trap, I
guess I must withdraw my view that flushing MACROLET would be a good way
of eliminating explicit environment hackery. It seems we must devote
our attention to fixing up the environment stuff rather than getting rid
of it.
One clarification we might want to consider would be an explicit
statement that FLET and LABELS can be used to shadow a MACRO (but not a
special form?) with a function. I bet a lot of implementations have
overlooked this possibility. I think that Spice Lisp did.
The macro subcommittee might change all fo this beyond recognition, of
course, but it's our job to patch up the existing langauge.
-- Scott
∂11-Jan-87 1938 FAHLMAN@C.CS.CMU.EDU Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 19:38:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 11 Jan 87 22:38:22-EST
Date: Sun, 11 Jan 1987 22:38 EST
Message-ID: <FAHLMAN.12270213953.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
In-reply-to: Msg of 9 Jan 1987 17:28-EST from Masinter.pa at Xerox.COM
I agree with the proposal and the analysis.
-- Scott
∂11-Jan-87 1938 FAHLMAN@C.CS.CMU.EDU Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 19:38:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 11 Jan 87 22:39:03-EST
Date: Sun, 11 Jan 1987 22:39 EST
Message-ID: <FAHLMAN.12270214075.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
In-reply-to: Msg of 9 Jan 1987 20:43-EST from Masinter.pa at Xerox.COM
I agree with the proposal and the analysis.
-- Scott
∂11-Jan-87 1939 FAHLMAN@C.CS.CMU.EDU Issue: IMPORT-UNCLEAR, Message 1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 19:39:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 11 Jan 87 22:39:52-EST
Date: Sun, 11 Jan 1987 22:39 EST
Message-ID: <FAHLMAN.12270214226.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: IMPORT-UNCLEAR, Message 1
In-reply-to: Msg of 9 Jan 1987 20:58-EST from Masinter.pa at Xerox.COM
I agree with the proposal and the analysis.
-- Scott
∂11-Jan-87 2015 RAM@C.CS.CMU.EDU Packages & Compiling
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87 20:14:55 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 11 Jan 87 23:15:13-EST
Date: Sun, 11 Jan 1987 23:15 EST
Message-ID: <RAM.12270220656.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Timothy.Freeman@THEORY.CS.CMU.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Packages & Compiling
In-reply-to: Msg of 11 Jan 1987 22:22-EST from Timothy.Freeman at theory.cs.cmu.edu
This is another thing that the compiler subcommittee should clear
up. In this case, it is not reasonable for the compiler to be
required to maintain the interpreted semantics. The problem is that
the compiler presumably uses the reader to read the source code, and
READ is not an information preserving operation.
Since CLTL doesn't admit this problem, it also doesn't properly
specify the package semantics of fasloading. There was some
discussion of this a while back, and we found that different
implementations were doing different things.
Although this part of the language is poorly specified, any
compiler which can't compile the same file twice is clearly broken.
I would "clarify" the requirement for an identical compile and
load environment to the following:
"To the extent which it matters, the package environment at the time
the compiler interns a symbol must be equivalent to the package
environment in which the loader interns the symbol."
This requirement isn't very useful to users, since it makes references
to the times at which the interning is done by the compiler and
loader. Especially in the loader, the time of interning may be
non-obvious.
In practice, there shouldn't be any problem as long as either:
1] The package environment used by a file is initialized using
top-level package manipulation code. The compiler will guarantee
that package operations done by such forms are properly sequenced
with respect to INTERN operations both in the compiler and the
loader.
2] Any other required aspects of the package environment are present
both at the beginning of the compilation of the file and the
beginning of the load of the fasl file.
The most common violation of these rules that I have seen it that a
user changes the package environment at load time, but doesn't use
obvious top-level package manipulation forms. In this case, the
compiler tends to get confused, causing the loader to attempt to
find packages that don't exist yet, or other bad things.
The real problem is that package manipulation forms look like ordinary
Lisp code, yet must be treated in a totally magical way by the
compiler.
Rob
∂11-Jan-87 2119 masinter.PA@Xerox.COM Re: Format of proposals
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jan 87 21:19:44 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 11 JAN 87 20:34:31 PST
From: masinter.PA@Xerox.COM
Date: 11 Jan 87 20:32:04 PST
Subject: Re: Format of proposals
In-reply-to: FAHLMAN@C.CS.CMU.EDU's message of Sun, 11 Jan 87 22:04 EST,
<FAHLMAN.12270207847.BABYL@C.CS.CMU.EDU>
To: FAHLMAN@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870111-203431-4227@Xerox>
I'm not sure my intentions in labelling the messages as Number 1 were
well thought out. If you'd like to consider them version numbers, so be
it. Given the distributed nature of the cleanup committee, I think I
should probably assign version numbers. Hopefully we wont have lots.
I'll adopt your suggestion of separating clearly the proposal and the
rationale.
∂12-Jan-87 1048 tsf@theory.cs.cmu.edu Re: Packages & Compiling
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 10:48:17 PST
Date: Monday, 12 January 1987 13:48:30 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: Rob MacLachlan <RAM@c.cs.cmu.edu>
cc: common-lisp@sail.stanford.edu, thomas.gross@sam.cs.cmu.edu
Subject: Re: Packages & Compiling
Message-ID: <1987.1.12.18.9.40.Timothy.Freeman@theory.cs.cmu.edu>
In-Reply-To: <RAM.12270220656.BABYL@C.CS.CMU.EDU>
We could make it possible for the compiler to maintain the interpreted
semantics in this case by making the read function take an optional
parameter, which would be function to use to intern the symbols
encountered. The default value of this parameter would be #'intern.
When the compiler is running, the value of this parameter would be a
function that looks at compiler data structures instead of the package
world. This would have several advantages:
It would allow the compiler to be reentrant.
It would make it possible for the compiler to understand
a "(use-package :foo)" (or any other package manipulating form)
without having to modify the package world.
Actually, the compiler is not required to call read, so this could
have been done on the initiative of the language implementor without
any change in the standard. I think that the following specification
of the compiler is implementable (argue with me if you disagree):
"The compiler is side-effect free and reentrant, and the semantics of
loading a compiled file is the same as the semantics of loading the
source, provided that all of the following are true:
1) Only the standard functions are used to manipulate the
package environment, and they are top-level forms in the
source.
2) Eval-when is not used.
3) All macros referenced by the source code are either defined
in the source code with a toplevel defmacro form before they
are used, or they are defined when the compiler is called.
4) All macros used are side-effect free and reentrant."
You said:
"To the extent which it matters, the package environment at the time
the compiler interns a symbol must be equivalent to the package
environment in which the loader interns the symbol."
What exactly did you mean by the phrase "to the extent which it
matters"?
∂12-Jan-87 1301 FAHLMAN@C.CS.CMU.EDU Mailing list
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 13:01:12 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 12 Jan 87 15:50:11-EST
Date: Mon, 12 Jan 1987 15:49 EST
Message-ID: <FAHLMAN.12270401715.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: rpg@SAIL.STANFORD.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, ram@C.CS.CMU.EDU, mcdonald@C.CS.CMU.EDU
Subject: Mailing list
Rob Maclachlan and Dave McDonald will be helping me in formulating
cleanup proposals and in spotting problems in existing proposals. If
there are no objections, I would like to add them to the CL-CLEANUP
mailing list so that they can receive this mail directly. In general,
they will be passing their suggests back through me, so their presence
on the list should not increase the overall mail volume.
ram@c.cs.cmu.edu
mcdonald@c.cs.cmu.edu
Thanks,
Scott
∂12-Jan-87 1403 DLW@ALDERAAN.SCRC.Symbolics.COM Packages & Compiling
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 12 Jan 87 14:03:24 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 38394; Mon 12-Jan-87 15:13:15 EST
Date: Mon, 12 Jan 87 15:12 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Packages & Compiling
To: Timothy.Freeman@theory.cs.cmu.edu, common-lisp@sail.stanford.edu
cc: edsel!bhopal!jonl@navajo.stanford.edu, thomas.gross@sam.cs.cmu.edu
In-Reply-To: <1987.1.12.2.10.27.Timothy.Freeman@theory.cs.cmu.edu>
Message-ID: <870112151228.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Sunday, 11 January 1987 22:22:19 EST
From: Timothy.Freeman@theory.cs.cmu.edu
CLtL specifies the compiler by saying that "compiling a file of code
should produce an equivalent but more efficient program". Jon is
saying "compiling a file of code should produce an equivalent but more
efficient program, provided that the package environment at compile
time is the same as the package environment at load time; otherwise
all bets are off". I can imagine ways of implementing compilers so
that the qualifier about the package environment is unneccessary.
It's also true that if the value of *read-base* is different when you do
the compilation, or if the read table has been altered in any way, all
bets are off. In other words, the phenomenon is not specific to
packages, but applies to any state information that affects the actions
of the Lisp reader. The compiler has to be careful to do its reading
with all the parameters set appropriately.
Our implementation normally accomplishes this by using "file attribute
lists", property-list-like things expressed in a special text string
that lives in a comment at the head of the file. However, this solution
was not adopted in the Common Lisp definition. I agree that there
probably is not an adequate replacement available in pure Common Lisp.
∂12-Jan-87 1533 RAM@C.CS.CMU.EDU Packages & Compiling
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 15:33:45 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 12 Jan 87 18:34:00-EST
Date: Mon, 12 Jan 1987 18:33 EST
Message-ID: <RAM.12270431603.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Timothy.Freeman@THEORY.CS.CMU.EDU
Cc: common-lisp@SAIL.STANFORD.EDU, thomas.gross@SAM.CS.CMU.EDU
Subject: Packages & Compiling
In-reply-to: Msg of 12 Jan 1987 13:48-EST from Timothy.Freeman at theory.cs.cmu.edu
Although it is not currently stated anywhere, it is definitely
required that the compiler use READ to parse input files. The whole
reason for having an extensible reader is that it allows people to
define read macros that can be used in code. Normal macros also
demand that source be represented as a s-expression, making life very
difficult for any scheme that tries to pass extra information from the
reader to the fasl-dumper.
It may be possible to preserve package qualification information
somehow, but I think any implementation would be unreasonably
difficult. It isn't worth "fixing" this problem, since there are
dozens of other equally intractable problems that prevent
COMPILE-FILE/LOAD from being identical to LOAD of the source.
The real problem is that LOAD of a source is over-specified, since
"everyone knows" that it is implemented by sequentially reading and
evaluating forms. What we need to do is come up with a more
restrictive semantics for a "code file" such that a well-formed code
file will do the same thing across the full range of legal
implementations of Common Lisp evaluation.
I won't discuss the non-package compiler issues that you mentioned,
since they open a moby can of worms. The rules you give are certainly
sufficient, but are not necessary.
I said "to the extent which it matters, the package environments must
be equivalent" to emphasize the unknown nature of "package
equivalence". All I can really say right now is that requiring the
package state to be "identical" is too restrictive.
Rob
∂12-Jan-87 1615 tsf@theory.cs.cmu.edu Re: Packages & Compiling
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 16:15:05 PST
Date: Monday, 12 January 1987 19:15:36 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: common-lisp@sail.stanford.edu
cc: edsel!bhopal!jonl@navajo.stanford.edu, thomas.gross@sam.cs.cmu.edu
Subject: Re: Packages & Compiling
Message-ID: <1987.1.12.23.41.38.Timothy.Freeman@theory.cs.cmu.edu>
In-Reply-To: <870112151228.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Mon, 12 Jan 87 15:12 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
It's also true that if the value of *read-base* is different when you do
the compilation, or if the read table has been altered in any way, all
bets are off. In other words, the phenomenon is not specific to
packages, but applies to any state information that affects the actions
of the Lisp reader. The compiler has to be careful to do its reading
with all the parameters set appropriately.
I don't have any problem with the values of a couple of special
variables affecting the behavior of the compiler for two reasons.
(This is not a statement about whether these dependencies should
exist; I'm just trying to say that they are less troublesome.)
If I start having problems with these variables having the wrong
value, I can always write a little function or macro that sets or
binds them to standard values.
I don't change the values I use for these variables often, so the
problem never really arises.
The dependency of the behavior of the compiler upon the package
environment does give me problems for the same two reasons:
It is normal for the code that is being compiled to change the
package environment, so there is no standard value for the package
environment.
I do change the package environment often, so this is a real
problem.
In general, the compilation process should not depend upon aspects of
the current environment which are not easy to change, unless that
dependency allows better code to be produced. Allowing the compiler
to depend upon the package environment when it is compiling a
not-in-line function call doesn't allow it to produce better code.
∂12-Jan-87 1640 KMP@STONY-BROOK.SCRC.Symbolics.COM mailing list requests
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Jan 87 16:40:11 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 41926; Mon 12-Jan-87 19:39:48 EST
Date: Mon, 12 Jan 87 19:38 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: mailing list requests
To: Joseph.Ginder@spice.cs.cmu.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <1987.1.7.15.59.57.Joseph.Ginder@spice.cs.cmu.edu>
Message-ID: <870112193832.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wednesday, 7 January 1987 11:02:14 EST
From: Joseph.Ginder@spice.cs.cmu.edu
For the record, where should one send mailing list requests for the
general common lisp mailing list and the various sub-lists?
Please send administrative requests such as list addition/removal requests
to RPG@SAIL.STANFORD.EDU (a.k.a. RPG@SU-AI.ARPA). Encourage your friends to
do likewise. Please do not send such requests to Common-Lisp. Thanks.
∂12-Jan-87 1711 RAM@C.CS.CMU.EDU Packages & Compiling
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jan 87 17:10:14 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 12 Jan 87 20:08:11-EST
Date: Mon, 12 Jan 1987 20:08 EST
Message-ID: <RAM.12270448749.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Timothy.Freeman@THEORY.CS.CMU.EDU
Cc: common-lisp@SAIL.STANFORD.EDU, edsel!bhopal!jonl@NAVAJO.STANFORD.EDU,
thomas.gross@SAM.CS.CMU.EDU
Subject: Packages & Compiling
In-reply-to: Msg of 12 Jan 1987 19:15-EST from Timothy.Freeman at theory.cs.cmu.edu
Date: Monday, 12 January 1987 19:15-EST
From: Timothy.Freeman at theory.cs.cmu.edu
Re: Packages & Compiling
... Allowing the compiler
to depend upon the package environment when it is compiling a
not-in-line function call doesn't allow it to produce better code.
True; it simply allows the compiler to function. The basic problem is
that if you use READ to read, there is no way to intern the symbol the
same way at load time, since the reader threw away the information
about how the symbol was read.
For example, if the source file contains the symbol reference FOO::X,
but X's home package is actually BAR, then the compiler will dump code
which does the equivalent of reading BAR::X at load time. The result
will be the X currently accessible in the BAR package, regardless
of what symbol is currently accessible in the FOO package.
In contrast, if FOO::X was read again by loading the source, then the
symbol would be read as whatever X is accessible in the FOO package.
Rob
∂13-Jan-87 0534 RWK@YUKON.SCRC.Symbolics.COM Re: Packages & Compiling
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 13 Jan 87 05:34:24 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 147830; Tue 13-Jan-87 08:29:34 EST
Date: Tue, 13 Jan 87 08:30 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Re: Packages & Compiling
To: Timothy.Freeman@theory.cs.cmu.edu
cc: common-lisp@sail.stanford.edu, edsel!bhopal!jonl@navajo.stanford.edu,
thomas.gross@sam.cs.cmu.edu
In-Reply-To: <1987.1.12.23.41.38.Timothy.Freeman@theory.cs.cmu.edu>
Message-ID: <870113083027.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Monday, 12 January 1987 19:15:36 EST
From: Timothy.Freeman@theory.cs.cmu.edu
Date: Mon, 12 Jan 87 15:12 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
It's also true that if the value of *read-base* is different when you do
the compilation, or if the read table has been altered in any way, all
bets are off.
If I start having problems with these variables having the wrong
value, I can always write a little function or macro that sets or
binds them to standard values.
In fact, the problem is not unique to the compiler.
We have a macro, WITH-STANDARD-IO-ENVIRONMENT,
which does this for all the read/print controls. The
idea is that you wrap this around anything which prints
with an expectation that something will later read it
with the same interpretation, and also around the
code which reads it.
Unfortunately, in a fit of blinding stupidity (and
there's AT LEAST a 50% chance it was MY stupidity)
we made it use ZL-USER instead of USER, thus saddling
ourselves with somewhat of a compatibility problem.
So I'd appreciate it if someone could come up with
a better name for a CL-standard version of this.
∂13-Jan-87 0537 RWK@YUKON.SCRC.Symbolics.COM Packages & Compiling
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 13 Jan 87 05:37:41 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 147826; Tue 13-Jan-87 08:20:43 EST
Date: Tue, 13 Jan 87 08:21 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Packages & Compiling
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
cc: Timothy.Freeman@THEORY.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU,
edsel!bhopal!jonl@NAVAJO.STANFORD.EDU, thomas.gross@SAM.CS.CMU.EDU
In-Reply-To: <RAM.12270448749.BABYL@C.CS.CMU.EDU>
Message-ID: <870113082109.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Mon, 12 Jan 1987 20:08 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Date: Monday, 12 January 1987 19:15-EST
From: Timothy.Freeman at theory.cs.cmu.edu
Re: Packages & Compiling
... Allowing the compiler
to depend upon the package environment when it is compiling a
not-in-line function call doesn't allow it to produce better code.
True; it simply allows the compiler to function. The basic problem is
that if you use READ to read, there is no way to intern the symbol the
same way at load time, since the reader threw away the information
about how the symbol was read.
For example, if the source file contains the symbol reference FOO::X,
but X's home package is actually BAR, then the compiler will dump code
which does the equivalent of reading BAR::X at load time. The result
will be the X currently accessible in the BAR package, regardless
of what symbol is currently accessible in the FOO package.
In contrast, if FOO::X was read again by loading the source, then the
symbol would be read as whatever X is accessible in the FOO package.
Rob
This has been discussed in the past. If the compiler doesn't
dump BAR::X, but rather just "X" (just like the printer would),
then the loader will make the same decisions the compiler
did. Dumping should be kept strictly analogous to printing,
and loading to reading, so far as package-prefix hacking is
concerned.
This certainly needs to be made a part of the standard, or
implementors aren't going to realize this and their users
are going to have the problems you refer to. We didn't
get it right our first time around, either.
This doesn't confer immunity to package-heirarchy changes,
of course. Among the ways you can lose at load time
include:
1) Refering to a package that is no longer there. Obviously,
a source change would have been necessary.
2) Making an exported symbol be unexported. (Although
a source change might have been necessary in this case,
too).
3) Moving a symbol from one package to another, when
you want to continue refering to the same symbol. Of
course, you have to change the source anyway, so it's
not suprising you have to recompile.
4) You said BAR::X, at compile time X was accessible in
FOO, but at run time, it was not. No source change is
necessary, because you already had it right.
But in practice, these aren't very serious, while it
is much more serious if you can't change which X
you import into your package. In fact, I think #2
and #4 are the only cases where you really do suffer
from READ not preserving information.
∂13-Jan-87 2046 Moon@RIVERSIDE.SCRC.Symbolics.COM Format of proposals
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 13 Jan 87 14:44:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 92766; Tue 13-Jan-87 15:02:43 EST
Date: Tue, 13 Jan 87 15:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Format of proposals
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12270207847.BABYL@C.CS.CMU.EDU>
Message-ID: <870113150100.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 11 Jan 1987 22:04 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Second, I'm wondering what Larry intends by the message numbers he
includes in the message headers....
I'd suggest that each revision to a specific proposal be given a number,
so that we can refer to "GET-SETF-METHOD-ENVIRONMENT, version 3245" or
whatever, but if we want to refer to messages themselves, something like
"Moon's mail of 1/11/86, 23:30" should do the job.
I agree that numbering the messages themselves doesn't make sense. I
believe the issues should be numbered; this makes tracking multiple
ongoing conversations considerably easier. I'm not happy with the idea
that Larry apparently sent out three different issues to start with, all
numbered 1. I think they should have been 1, 2, and 3. Or maybe 20,
21, and 22, to avoid clashing with the numbers from last spring. (For
some reason those messages never got to me, only Scott's replies saying
he agreed with them. Where were they sent?)
Let me restate this a different way. I think numbers should be assigned
to each issue, uniquely identifying that issue. I don't think the unique
identifier should be a combination of some descriptive text and a version
number; descriptive text tends to be gradually mutated as the conversation
progresses, something like playing "telephone". As for version numbers, if
an issue (or a proposal for an issue) is revised so drastically that previous
discussion is irrelevant and a new number should be assigned, then a new
issue number should be assigned. Maybe it's a good idea to relate it to
the previous version number, e.g. if initially it was issue 69, then the
first revision is issue 69.1.
∂13-Jan-87 2053 RAM@C.CS.CMU.EDU Packages & Compiling
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Jan 87 16:08:50 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 13 Jan 87 19:08:13-EST
Date: Tue, 13 Jan 1987 19:08 EST
Message-ID: <RAM.12270699974.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Robert W. Kerns" <RWK@SCRC-YUKON.ARPA>
Cc: common-lisp@SAIL.STANFORD.EDU, thomas.gross@SAM.CS.CMU.EDU
Subject: Packages & Compiling
In-reply-to: Msg of 13 Jan 1987 08:21-EST from Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
Date: Tuesday, 13 January 1987 08:21-EST
From: Robert W. Kerns <RWK at YUKON.SCRC.Symbolics.COM>
Re: Packages & Compiling
... Dumping should be kept strictly analogous to printing,
and loading to reading, so far as package-prefix hacking is
concerned.
This is a reasonable way to dump symbols, but it isn't obvious to me
that it is the only correct way. In fact, it would have made no
difference in my example, since I was assuming that X wasn't
accessible in the current package. It is a question of how far we
require implementations to go in allowing changes in the package
environment. I think an argument can be made for requiring a more strict
equivalence, which would still allow your interpretation to be legal.
Rob
∂14-Jan-87 0631 FAHLMAN@C.CS.CMU.EDU Mail problems
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 06:30:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 Jan 87 09:30:59-EST
Date: Wed, 14 Jan 1987 09:30 EST
Message-ID: <FAHLMAN.12270857044.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Mail problems
Larry and I were wondering why the rest of you were so quiet -- whether
you were just busy for awhile or had given up on the whole thing. Now
it appears taht some of you, at least, have not been getting all the
mail. Larry's first three proposals went out before the CL-CLEANUP
mail reflector was in use. I'll remail them, along with other
contentful mail, to CL-CLEANUP.
Just to make sure that everyone is receiving this list properly, please
send a brief message to CL-CLEANUP@SU-AI containing the secret word
"axolotl" when and if you receive this message.
-- Scott
∂14-Jan-87 0633 FAHLMAN@C.CS.CMU.EDU [Fahlman: Issues file]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 06:33:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 Jan 87 09:33:50-EST
Date: Wed, 14 Jan 1987 09:33 EST
Message-ID: <FAHLMAN.12270857566.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Fahlman: Issues file]
Date: Friday, 9 January 1987 00:39-EST
From: Scott E. Fahlman <Fahlman>
To: gls at ZARATHUSTRA.THINK.COM, masinter.pa at XEROX.COM,
hpfclp!dcm at HPLABS.HP.COM, kmp at SCRC-STONY-BROOK.ARPA,
"edsel!jonl" at NAVAJO.STANFORD.EDU, fahlman,
moon at SCRC-STONY-BROOK.ARPA
cc: rpg at SAIL.STANFORD.EDU, Mathis at ADA20.ISI.EDU
Re: Issues file
[Mail to Dave Matthews still seems to be bouncing most of the time.
Sigh! Maybe H-P should break down and buy a Vax to handle mail. I
don't think you can buy Dec-20's these days.]
I have reorganized the old ISSUES.TXT file and cleaned it up some. It
may prove useful as an inventory of the things we ought to work on.
This file is on C.CS.CMU.EDU in PRVA:<SLISP.STANDARD>ISSUES.TXT. It
should be FTP'able from there. If you have trouble, let me know and
I'll mail you a copy.
I have not added any issues raised since last summer's Lisp Conference.
I have included the formal proposals from last summer in this file in
stripped-down form, more or less as place-holders. I have not yet tried
to sift through all that mail to find all of the options and amendments
that people proposed in discussing these proposals.
It think that it would be encouraging to everyone if we could come up
with specific proposals on a bunch of easy, obvious clarifications in
time for the next meeting, if we can find some easy ones. We also
should at least come up with a plan of action for the harder issues.
I take your silence on the issue of chairmanship as assent. I now
resign my temporary leadership of this committee to Larry Masinter. As
chairman, it will be up to him to manage the discussions from this
point. Of course, I will continue to do some of the work on various
technical issues.
-- Scott
∂14-Jan-87 0634 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issues file]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 06:34:18 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 Jan 87 09:34:23-EST
Date: Wed, 14 Jan 1987 09:34 EST
Message-ID: <FAHLMAN.12270857666.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Masinter.pa: Issues file]
Date: Friday, 9 January 1987 16:48-EST
From: Masinter.pa at Xerox.COM
To: Fahlman
cc: gls at ZARATHUSTRA.THINK.COM, masinter.pa at Xerox.COM,
hpfclp!dcm at HPLABS.HP.COM,
kmp at SCRC-STONY-BROOK.SYMBOLICS.COM,
"edsel!jonl" at NAVAJO.STANFORD.EDU,
moon at SCRC-STONY-BROOK.SYMBOLICS.COM,
rpg at SAIL.STANFORD.EDU, Mathis at ADA20.ISI.EDU
Re: Issues file
I will try to get a distribution list created soon.
My notion is that it will be easier to get consensus on each of these if
we can relate the proposals we adopt to the charter of the group, viz:
* This issue is a mistake, ambiguity of minor ommission in Common Lisp:
the Language
* It is not being addressed by another group (the most serious
interactions in the proposals so far are those that might belong to the
'semantics of compilation' group)
and, where relevant:
* this codifies existing practice, facilitates portability of code, or
establishes normative programming practice
* the cost of adopting the change
* the cost of not-adopting the change
* the cost of conversion of existing code
* a "ramp-up" mechanism for introducing the change
* other aesthetic critera
I will broadcast the issues one at a time with alternatives. I will
generate a unique ID for each issue (e.g., CLARIFY-FUNCTION-DECLARATION)
& proposal (e.g., CLARIFY-FUNCTION-DECLARATION-1). Please use the ID in
the subject of your message.
I'd like to sort the issues by how quickly I think we can reach
consensus on them; does anyone prefer a different order?
I'd like to at least ask the "compiler" committee if they would take on
the ones that had to do with declarations (e.g., the function/ftype
declarations.) Does anyone think that we should tackle them first
without asking them?
∂14-Jan-87 0634 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 06:34:37 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 Jan 87 09:34:49-EST
Date: Wed, 14 Jan 1987 09:34 EST
Message-ID: <FAHLMAN.12270857740.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Masinter.pa: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1]
Date: Friday, 9 January 1987 17:28-EST
From: Masinter.pa at Xerox.COM
To: Fahlman, gls at ZARATHUSTRA.THINK.COM, masinter.pa at Xerox.COM,
hpfclp!dcm at HPLABS.HP.COM,
kmp at SCRC-STONY-BROOK.SYMBOLICS.COM,
"edsel!jonl" at NAVAJO.STANFORD.EDU,
moon at SCRC-STONY-BROOK.SYMBOLICS.COM,
rpg at SAIL.STANFORD.EDU, Mathis at ADA20.ISI.EDU
Re: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
(Note: this is a sample of the format I had in mind.)
Please reply if you
a) agree with the analysis and vote for adopting the proposal
b) disagree with the analysis; if so, please explain briefly
c) have an alternative proposal
Issue: (Steele, p. 106) If a macro that performs similar processing to
SETF uses GET-SETF-METHOD, and that macro occurs within a MACROLET, the
expansion will not see the MACROLET definition, e.g.
(defmacro special-incf ... (get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Classification: This is a mistake in CLtL.
Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to GET-SETF-METHOD. If the argument
is not supplied, you get the null lexical environment.
Allow DEFINE-SETF-METHOD to take an ENVIRONMENT argument.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Rationale:
a) this codifies existing practice: many Common Lisp implementations
already have adopted this change.
b) the cost of adopting this change is small but non-zero: some
implementations must change their definitions.
c) the cost of converting existing code is zero, since this is an upward
compatible change. However, implementations which did not already take
into account the lexical environment for SETF'd forms might start
working differently if the internal implementation of SETF is changed.
d) this is an upward compatible change, so that the staging is simple.
Other aesthetic critera:
Adding environment arguments to get-setf-method complicates it and its
callers. An alternative, removing MACROLET, would result in a simpler
language. If the rest of the language were changed so that there were no
differences between the interpretation of setfs in any lexical context,
the environment argument would be extraneous.)
∂14-Jan-87 0635 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 06:34:59 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 Jan 87 09:35:08-EST
Date: Wed, 14 Jan 1987 09:35 EST
Message-ID: <FAHLMAN.12270857798.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Masinter.pa: Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1]
Date: Friday, 9 January 1987 20:43-EST
From: Masinter.pa at Xerox.COM
To: Fahlman, gls at ZARATHUSTRA.THINK.COM, masinter.pa at Xerox-COM.ARPA,
hpfclp!dcm at HPLABS.HP.COM,
kmp at SCRC-STONY-BROOK.SYMBOLICS.COM,
edsel!jonl at NAVAJO.STANFORD.EDU,
moon at SCRC-STONY-BROOK.SYMBOLICS.COM,
rpg at SAIL.STANFORD.EDU, Mathis at ADA20.ISI.EDU
Re: Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
(I am not sure I realized how big this "issues" file was! However, it
seems useful to have the examples placed in the paperwork we present to
X3j13 so we don't have to go through the justifications again.)
Please reply if you
a) agree with the analysis and vote for adopting the proposal
b) disagree with the analysis; if so, please explain briefly
c) have an alternative proposal
Issue: (Steele, p. 144) The macro function associated with a given
symbol depends on the lexical context of that symbol, and can differ
inside a MACROLET (which introduces lexical macros), or inside a FLET or
LABELS (which shadow macros). However, there is no way to account for
this lexical context in macros which know their environment (using the
&ENVIRONMENT argument) and which do their own macro expansion.
Example:
(defmacro example (form &environment environment)
(let ((macro (macro-function (car form)))
(when macro .... (funcall macro form) ...)
Normally, the macro-function definition reflects the interpretation of
the FORM argument to EXAMPLE. However, within a MACROLET it does not.
Classification: This is a mistake in CLtL.
Proposal MACRO-FUNCTION-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to MACRO-FUNCTION. If the argument
is not supplied, you get the null lexical environment. Otherwise, the
environment argument is used to determine the macro definition.
The example above could then be coded:
(defmacro example (form &environment environment)
(let ((macro (macro-function (car form) environment))
(when macro .... (funcall macro form) ...)
Rationale:
a) this codifies existing practice: many Common Lisp implementations
already have adopted this change.
b) the cost of adopting this change is small but non-zero: some
implementations must change their definitions.
c) the cost of converting existing code is zero, since this is an upward
compatible change.
d) this is an upward compatible change, so that the staging is simple.
Other aesthetic critera:
Adding an environment argument to MACRO-FUNCTION complicates it and its
callers. An alternative, removing MACROLET, would result in a simpler
language. If the rest of the language were changed so that there were no
differences between the interpretation of macros in any lexical context,
the environment argument would be extraneous.
∂14-Jan-87 0635 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issue: IMPORT-UNCLEAR, Message 1]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 06:35:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 Jan 87 09:35:27-EST
Date: Wed, 14 Jan 1987 09:35 EST
Message-ID: <FAHLMAN.12270857859.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Masinter.pa: Issue: IMPORT-UNCLEAR, Message 1]
Date: Friday, 9 January 1987 20:58-EST
From: Masinter.pa at Xerox.COM
To: Fahlman, gls at ZARATHUSTRA.THINK.COM, masinter.pa at Xerox.COM,
hpfclp!dcm at HPLABS.HP.COM,
kmp at SCRC-STONY-BROOK.SYMBOLICS.COM,
edsel!jonl at NAVAJO.STANFORD.EDU,
moon at SCRC-STONY-BROOK.SYMBOLICS.COM,
rpg at SAIL.STANFORD.EDU, Mathis at ADA20.ISI.EDU
Re: Issue: IMPORT-UNCLEAR, Message 1
(This is the last one I will send out until I get some replies. I had
some trouble with elaborating this one, which I think means that I don't
understand the issue. )
Reference: Steele p. 186.
Issue: The action of IMPORT on the home package of a symbol is not
described well, as it affects the "home package" of a symbol.
Classification: clarification.
Proposal IMPORT-UNCLEAR:REWRITE:
Change the description of IMPORT to say: "if any symbol to be imported
has no home package, then IMPORT sets the home package of the symbol to
the specified package being imported to."
Clarify that INTERN does not modify a symbol's home package. Rewrite
the section avoiding the verb "intern", as it confuses everyone.
Rationale:
a) this codifies existing practice: all Common Lisp implementations work
this way.
b) the cost of adopting this change is small: it requires rewriting the
section.
c) the cost of not adopting the change is continued confusion about how
Common Lisp works, and the risks that some new implementations will not
work this way.
d) the cost of converting existing code is zero; this is just a rewrite.
∂14-Jan-87 0645 FAHLMAN@C.CS.CMU.EDU [Masinter.pa: Issue: IMPORT-UNCLEAR, Message 1]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 06:44:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 Jan 87 09:44:59-EST
Date: Wed, 14 Jan 1987 09:44 EST
Message-ID: <FAHLMAN.12270859593.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [Masinter.pa: Issue: IMPORT-UNCLEAR, Message 1]
Date: Friday, 9 January 1987 20:58-EST
From: Masinter.pa at Xerox.COM
To: Fahlman, gls at ZARATHUSTRA.THINK.COM, masinter.pa at Xerox.COM,
hpfclp!dcm at HPLABS.HP.COM,
kmp at SCRC-STONY-BROOK.SYMBOLICS.COM,
edsel!jonl at NAVAJO.STANFORD.EDU,
moon at SCRC-STONY-BROOK.SYMBOLICS.COM,
rpg at SAIL.STANFORD.EDU, Mathis at ADA20.ISI.EDU
Re: Issue: IMPORT-UNCLEAR, Message 1
(This is the last one I will send out until I get some replies. I had
some trouble with elaborating this one, which I think means that I don't
understand the issue. )
Reference: Steele p. 186.
Issue: The action of IMPORT on the home package of a symbol is not
described well, as it affects the "home package" of a symbol.
Classification: clarification.
Proposal IMPORT-UNCLEAR:REWRITE:
Change the description of IMPORT to say: "if any symbol to be imported
has no home package, then IMPORT sets the home package of the symbol to
the specified package being imported to."
Clarify that INTERN does not modify a symbol's home package. Rewrite
the section avoiding the verb "intern", as it confuses everyone.
Rationale:
a) this codifies existing practice: all Common Lisp implementations work
this way.
b) the cost of adopting this change is small: it requires rewriting the
section.
c) the cost of not adopting the change is continued confusion about how
Common Lisp works, and the risks that some new implementations will not
work this way.
d) the cost of converting existing code is zero; this is just a rewrite.
∂14-Jan-87 0727 MATHIS@ADA20.ISI.EDU axolotl
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 07:27:15 PST
Date: 14 Jan 1987 07:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: axolotl
From: MATHIS@ADA20.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]14-Jan-87 07:15:04.MATHIS>
axolotl -- now does a duck come down? -- Bob
∂14-Jan-87 1056 FAHLMAN@C.CS.CMU.EDU axolotl
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 10:56:05 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 14 Jan 87 13:50:02-EST
Date: Wed, 14 Jan 1987 13:49 EST
Message-ID: <FAHLMAN.12270904194.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: axolotl
In-reply-to: Msg of 14 Jan 1987 10:15-EST from MATHIS at ADA20.ISI.EDU
axolotl -- now does a duck come down? -- Bob
________
| Quack? |
--------
_ /
/@@____ _ /
| ____]
\ / /
\------/ /
\ << /
\____/
| |
<]<]
∂14-Jan-87 1131 Margolin.VS3@BCO-MULTICS.ARPA &function
Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 14 Jan 87 11:30:07 PST
Date: Wed, 14 Jan 87 14:12 EST
From: Barry Margolin <Margolin@BCO-MULTICS.ARPA>
Subject: &function
To: common-lisp@SU-AI.ARPA
Message-ID: <870114191239.078904@BCO-MULTICS.ARPA>
I brought the following proposal up during the December X3J13 meeting,
and it was requested that I send it to the list to allow for easier
digesting and further discussion.
We were discussing the pros and cons of merging the function and value
namespaces. One of the issues used to support the single namespace is
that functional arguments are clumsy to use when FUNCALL is required,
and this may inhibit people from using high-order function composition.
I'm not sure I really agree that it is a significant deterrent, and
there are reasonable arguments in favor of requiring FUNCALL, but for
the purpose of this discussion let's assume that it is.
So, the one-namespace people argue that
(defun twice (fun)
#'(lambda (x) (fun (fun x))))
is clearer than
(defun twice (fun)
#'(lambda (x) (funcall fun (funcall fun x))))
This is then used as an argument that the value and function cells of
variables should be identical. My proposal allows functional arguments
to be called without using FUNCALL, but still retaining the distinct
namespaces. My version of the above function would be
(defun twice (&function fun)
#'(lambda (x) (fun (fun x))))
The keyword &function in the lambda list indicates that the functional
interpretation of the following parameter should be bound, rather than
the value interpretation. This is analogous to the distinction between
LET and FLET.
This keyword also serves a secondary function, that of documenting the
fact that a particular parameter is expected to be a function. This is
useful for programmers, and compilers can also assume a default
declaration for the parameter.
One of the issues that was brought up when I proposed this at the
meeting is that it lacks one important feature that FLET has: the lambda
list of the local function. This could be solved in two ways. First,
the &function syntax could be extended, so that it is
&function name lambda-list
I don't really care for this, because it puts a whole lot of stuff in the
outer function's lambda list, and because two list elements are used
for one parameter (the latter could be dealt with by making it
&function (name lambda-list)
). The other solution is to use a declaration at the beginning of the
function body to specify the calling sequence. This would be necessary
in order to specify the types of the arguments. The two mechanisms
could be combined, so that the syntax would be
&function (name arg-typespecs)
since there would be no use for argument names anyway (except for
self-documentation purposes).
&function can also be described in terms of a source transformation.
The example function could be rewritten as
(defun twice (g0001)
(flet ((fun (&rest args) (apply g0001 args)))
#'(lambda (x) (fun (fun x)))))
Of course, it gets more complicated when the ideas for specifying the
arguments are added, but no one ever said compiler writing was easy.
barmar
∂14-Jan-87 1232 RPG Batrachian reptile
To: cl-cleanup@SAIL.STANFORD.EDU
Axolotl
-rpg-
∂14-Jan-87 1337 Moon@STONY-BROOK.SCRC.Symbolics.COM Lack of mail problems
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Jan 87 13:36:55 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43751; Wed 14-Jan-87 14:45:39 EST
Date: Wed, 14 Jan 87 14:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Lack of mail problems
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12270857044.BABYL@C.CS.CMU.EDU>
Message-ID: <870114144544.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Neotenous salamander.
∂14-Jan-87 1546 tsf@theory.cs.cmu.edu &function
Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jan 87 15:46:38 PST
Date: Wednesday, 14 January 1987 18:45:28 EST
From: Timothy.Freeman@theory.cs.cmu.edu
To: Barry Margolin <Margolin@bco-multics.arpa>
cc: common-lisp@sail.stanford.edu
Subject: &function
Message-ID: <1987.1.14.23.10.37.Timothy.Freeman@theory.cs.cmu.edu>
I'm not sure I really agree that it is a significant deterrent, and
there are reasonable arguments in favor of requiring FUNCALL, but for
the purpose of this discussion let's assume that it is.
Each irregularity of the language requires some effort to learn.
Since normal variable evaluation is much more common than funcalls,
the requirement to learn the semantics of funcall is an deterrent to
using it. Unless there is some benefit gained from the irregularity,
it shouldn't exist.
The keyword &function in the lambda list indicates that the functional
interpretation of the following parameter should be bound, rather than
the value interpretation. This is analogous to the distinction between
LET and FLET.
Okay, but this only eliminates the funcall's for variables which
appear as arguments. What about variables that are not arguments? Is
there any reason it should be easier to invoke a function object that
came in as an argument than one that didn't? More irregularities in
our language...
This keyword also serves a secondary function, that of documenting the
fact that a particular parameter is expected to be a function. This is
useful for programmers, and compilers can also assume a default
declaration for the parameter.
Is there some reason we need documentation that a variable is a
function but we don't need documentation that a variable is an
integer? This is an argument for going to a strongly typed language
(or one that has a very irregular structure).
I think the one-namespace arrangement is easier to understand and use
than what we have now. Does anyone have any explanation of why the
double-namespace arrangement should be kept? I think the burden of
proof should be on the people supporting the more complex scheme. (No
pun intended.)
∂14-Jan-87 1720 Masinter.pa@Xerox.COM Re: Batrachian reptile
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Jan 87 17:20:34 PST
Received: from Salvador.ms by ArpaGateway.ms ; 14 JAN 87 15:20:54 PST
Date: 14 Jan 87 13:06 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Batrachian reptile
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 14 Jan 87
12:32 PST
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870114-152054-757@Xerox>
What the axolotl ?
∂14-Jan-87 1938 Masinter.pa@Xerox.COM Re: &function
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 14 Jan 87 19:36:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 87 17:43:06 PST
Date: 14 Jan 87 17:44 PST
From: Masinter.pa@Xerox.COM
Subject: Re: &function
In-reply-to: Timothy.Freeman@theory.cs.cmu.edu's message of Wed, 14 Jan
87 18:45:28 EST
To: Timothy.Freeman@theory.cs.cmu.edu
cc: common-lisp@sail.stanford.edu
Message-ID: <870114-174306-1126@Xerox>
It is unfortunately the case that the "burden of proof" necessarily lies
on those would would modify Common Lisp. In particular, it is clearly
part of the charter of the Common Lisp standards group that changes to
Common Lisp only be made after explicit consideration of the costs
involved.
There is a very good 40-page paper by Richard Gabriel and Kent Pitman
which goes into some details of all of the complex interactions that
one-namespace would have with a variety of other features of Common
Lisp, including macros, default dynamic binding for free references,
etc.
I recommend it as required background reading.
∂15-Jan-87 0136 edsel!bhopal!jonl@navajo.stanford.edu Packages & Compiling
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Jan 87 01:35:59 PST
Received: by navajo.stanford.edu; Thu, 15 Jan 87 01:34:54 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01027; Thu, 15 Jan 87 00:37:46 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA01969; Thu, 15 Jan 87 01:17:39 PST
Date: Thu, 15 Jan 87 01:17:39 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701150917.AA01969@bhopal.edsel.uucp>
To: navajo!Timothy.Freeman%theory.cs.cmu.edu@navajo.stanford.edu
Cc: navajo!common-lisp%su-ai@navajo.stanford.edu,
navajo!thomas.gross%sam.cs.cmu.edu@navajo.stanford.edu
In-Reply-To: Timothy.Freeman@theory.cs.cmu.edu's message of Sunday, 11 January 1987 22:22:19 EST
Subject: Packages & Compiling
The quotation you attribute to me is a little bit out of context in that
the phrase
". . . requirement that the package world be EXACTLY the same at
load time that it was at compile time."
wasn't meant to imply that you will be guaranteed to lose when that
"requirement" is violated -- only that you can't be guaranteed to win.
In particular, lots of trivial such violations occur all the time, with
no lossage.
The kind of lossage you and Tom Gross had experienced may have been
caused by a different set of using packages between the compilation
environment and the load time environment. At any rate, such a
difference (in the package-use-list of your application package) may
or may not cause trouble -- depends upon whether your compiled file
uses any of the symbols that were accessible via inheritance from the
package that was "used" at compile time but missing at load time, or
has any symbols which are expected to be created in the application
package but which are spuriously inherited from a used package that
wasn't also used at compile time.
There are other possible problems too, but they are not all related to
compilation. For example, it is not at all difficult to cook up a
little test file that will "act differently" when merely loaded in
interpretively two times in a row. But of course, loading a compiled
file compounds the number of cases in which you may lose because,
typicaly, the compiled-file "reader" is not at all the same as READ.
In general, however, you are touching on the issue of insulating the
compilation environment from *any* side-effects occuring in the lisp
before the file compilation in question, including those caused by
previous compilations. You specifically bring up only the issue of
compiling a file twice, and seeing a different package environment the
second time. But the potential for lossage is much more complex than
merely package side effects; for example, think of macro definitions --
do you want them visible or not? maybe sometimes "yes" and sometimes "no".
There was a paper in the 1986 Lisp Conference on an "Un-Common Lisp"
that mentioned one partial solution the the issue. There is also an
ANSI sub-committee addressing the issue of compilation semantics -- perhaps
they will attempt to define just how much insulation you can expect. Quite
possibly, they should address the semantics of just how the compiled file
reader can differ from READ.
-- JonL --
∂15-Jan-87 0606 @HI-MULTICS.ARPA:Margolin.Multics@HIS-PHOENIX-MULTICS.ARPA Re: &function
Received: from HI-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jan 87 06:06:11 PST
Received: from HIS-PHOENIX-MULTICS.ARPA by HI-MULTICS.ARPA dial; 14-Jan-1987 19:33:48-cst
Sender: Barry Margolin <Margolin@HIS-PHOENIX-MULTICS.ARPA>
Date: Wed, 14 Jan 87 17:34 MST
From: Barry Margolin <Margolin@HIS-BILLERICA-MULTICS.ARPA>
Subject: Re: &function
To: Timothy.Freeman@THEORY.CS.CMU.EDU
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 14 Jan 87 16:45 MST from "Timothy.Freeman at THEORY.CS.CMU.EDU"
Message-ID: <870115003457.658506@HIS-PHOENIX-MULTICS.ARPA>
Okay, but this only eliminates the funcall's for variables which
appear as arguments. What about variables that are not arguments? Is
there any reason it should be easier to invoke a function object that
came in as an argument than one that didn't? More irregularities in
our language...
If a global variable is holding a function, the right place to put it is
in the function cell, not the value cell. The analogy here is that
"&function symbol" is to "defun symbol" as "symbol" is to "setq symbol".
What you didn't mention, but perhaps meant to imply, is that FUNCALL
would still be required when the function is in a computed location,
such as on a property list. Scheme would allow
((get symbol indicator) args)
but Common Lisp with &function still wouldn't. I will grant you this.
This keyword also serves a secondary function, that of documenting the
fact that a particular parameter is expected to be a function. This is
useful for programmers, and compilers can also assume a default
declaration for the parameter.
Is there some reason we need documentation that a variable is a
function but we don't need documentation that a variable is an
integer? This is an argument for going to a strongly typed language
(or one that has a very irregular structure).
Those of us who believe in two namespaces feel that the distinction
between function names and variable names is more important than the
distinction between integers and floats. Even for heavy users of
functional programming, I'm sure that most of the time functions are
called, not passed around as data.
I think the one-namespace arrangement is easier to understand and use
than what we have now. Does anyone have any explanation of why the
double-namespace arrangement should be kept?
Have you read KMP and RPG's paper, "Issues of Separation in Function
Cells and Value Cells"? It gives the many arguments on both sides of
the issue. It is document X3J13/86-010, and it was sent out to all
X3J13 members before the December meeting. If you are not a member, you
can probably get a copy from someone who is (Scott Fahlman is the only
CMU person who comes to mind immediately).
I think the burden of
proof should be on the people supporting the more complex scheme. (No
pun intended.)
I think that the burden of proof should be on the people favoring
changing the language. Common Lisp is mostly descended from a long
line of two-namespace dialects, it is already building a strong
following, so an incompatible change of this magnitude should only be
made if the language without the change is severely deficient. People
have been doing significant programming in MacLisp and Zetalisp for two
decades, so I don't think the two namespaces limits the usefulness of
the language greatly.
barmar
∂15-Jan-87 0821 RPG Issues of Function Cell
To: common-lisp@SAIL.STANFORD.EDU
The TEX source for the paper ``Issues of Separation in Function Cells and
Value Cells'' is in the file FUNCEL.TEX[COM,LSP], which can be FTPed
without login. You might have a little trouble with the Tex instructions
scattered throughout, and this version of the paper is the next-to-last
draft.
-rpg-
∂15-Jan-87 0827 gls@think.com Mail problems
Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 15 Jan 87 08:23:30 PST
Received: from Godot.Think.COM by zarathustra.think.com; Thu, 15 Jan 87 11:22:54 EST
Received: from desiderius by Godot.Think.COM via CHAOS; Thu, 15 Jan 87 11:22:44 EST
Date: Thu, 15 Jan 87 11:23 EST
From: Guy Steele <gls@think.com>
Subject: Mail problems
To: Fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
In-Reply-To: <FAHLMAN.12270857044.BABYL@C.CS.CMU.EDU>
Message-Id: <870115112348.3.GLS@DESIDERIUS.THINK.COM>
The LispM Function-Q screen image dump to the QMS has been
broken since we switched to Unix 4.3. It persistently puts
a ↑p ↑pm↑- mumble somewhere on the page about 95% of the
time you ask for a screen dump.
I have been asking for this to be fixed since the day after
we switched to 4.3. I have asked about one dozen times now.
I have been promised a couple of axolotl times that it would
be fixed in the next day or so (last such promise was about
one month ago).
∂15-Jan-87 1935 edsel!bhopal!jonl@navajo.stanford.edu Snakes and Lizards!
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 Jan 87 19:35:47 PST
Received: by navajo.stanford.edu; Thu, 15 Jan 87 19:34:11 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA00681; Thu, 15 Jan 87 19:11:50 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA02690; Thu, 15 Jan 87 19:08:48 PST
Date: Thu, 15 Jan 87 19:08:48 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701160308.AA02690@bhopal.edsel.uucp>
To: navajo!cl-cleanup%su-ai@navajo.stanford.edu
Subject: Snakes and Lizards!
"Axolotl" on you, too!
-- JonL --
∂15-Jan-87 2043 hpfclp!dcm@hplabs.HP.COM axolotl
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 15 Jan 87 20:42:24 PST
Received: by hplabs.HP.COM ; Thu, 15 Jan 87 19:26:15 pst
From: hpfclp!dcm@hplabs.HP.COM
Received: by hpfclp; Thu, 15 Jan 87 10:13:07 mst
Date: Thu, 15 Jan 87 10:13:07 mst
Return-Path: <hpfclp!dcm>
Received: from hpfcdcm.UUCP; Thu, 15 Jan 87 10:08 MST
To: +cl/cleanup@hplabs.HP.COM, hpfclp!cl-cleanup@sail.stanford.edu
Subject: axolotl
A water doll?
Dave Matthews
∂16-Jan-87 0643 vanroggen%bizet.DEC@decwrl.DEC.COM LISP POINTERS newsletter announcement
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 16 Jan 87 06:43:21 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA21565; Fri, 16 Jan 87 06:43:30 PST
Message-Id: <8701161443.AA21565@decwrl.dec.com>
Date: Friday, 16 Jan 1987 06:42:06-PST
From: vanroggen%bizet.DEC@decwrl.DEC.COM
To: common-lisp@sail.stanford.edu, vanroggen%bizet.DEC@decwrl.DEC.COM
Subject: LISP POINTERS newsletter announcement
*** ANNOUNCEMENT ***
LISP POINTERS
We're putting together a newsletter and we'd like you to come along.
Every other month, starting in March of 1987, Lisp Pointers will
be bringing you articles, implementation summaries, opinion columns,
and information on the lastest action on the standardization front.
And we need you -- to contribute to our departments, to read the
results of our efforts, and to suggest ways we can provide more of the
kinds of information you want to see.
Lisp Pointers is being funded by companies who care about the future
of Lisp. The editorial content of the newsletter will not be
influenced by these companies nor will the companies be responsible
for the material contained within Lisp Pointers. Until such time as
we affiliate with a more formal organization, subscriptions to Lisp
Pointers will be free. Please spread the word among your friends,
both real and electronic.
Our newsletter will be available through the mails. To join our
mailing list, send your name and address to:
Mary S. Van Deusen, Editor
IBM Research
PO Box 704
Yorktown Heights, New York 10598
914-789-7845
617-384-2526
MAIDA@IBM.COM
Contributions should be sent directly to the appropriate department:
***LETTERS TO THE EDITOR, NEWS ITEMS***
Mary S. Van Deusen (see above)
***IMPLEMENTATIONS***
Walter van Roggen
DEC
77 Reed Road
HL02-3/E9
Hudson, Massachusetts 01749
617-568-5617
VANROGGEN%BACH.DEC@DECWRL.DEC.COM
***BOOK REVIEWS, BIBLIOGRAPHIES***
Daniel Weinreb
Symbolics, Inc.
11 Cambridge Center
Cambridge, Massachusetts 02142
617-577-7500
DLW@MC.LCS.MIT.EDU
***X3J3 LISP STANDARDIZATION***
Robert F. Mathis
9712 Ceralene Drive
Fairfax, Virginia 22032
703-425-5923
mathis@b.isi.edu
***USERS***
Susan Ennis
Amoco Production Co.
PO Box 3385
Tulsa, Oklahoma 74102
918-660-3588
***TECHNICAL ARTICLES***
Jonl White
Lucid, Inc.
707 Laurel Street
Menlo Park, California 94025
415-329-8400
edsel!bhopal!jonl@navajo.stanford.edu
***ENVIRONMENTS***
John Foderaro
Franz Inc.
1141 Harbor Bay Parkway
Suite 270
Alameda, California 94501
415-769-5656
jkf%franz.uucp@berkeley.edu
***SCHEME***
Will Clinger M/S 50-662
Tektronics Inc.
PO Box 500
Beaverton, Oregon 97077
willc%tekchips@tek.csnet
503-627-4675
***LISP QUESTIONS***
Patrick Dussud
Texas Instruments
12501 Research Boulevard
MS 2201
Austin, Texas 78759
dussud%jenner%ti-csl.csnet@csnet-relay
***INTERNATIONAL ISSUES***
Christian Quiennec
LITP
4 Place Jussieu
F-75252, Paris Cedex 05
FRANCE
tel: +33 (1) 43 36 25 25 x 5251
UUCP: ..!mcvax!inria!queinnec
ARPA: mcvax!inria!queinnec@seismo.css.GOV
∂16-Jan-87 1432 primerd!doug@enx.prime.pdn
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 14:31:26 PST
Received: by EDDIE.MIT.EDU (5.31/4.7) id AA02993; Fri, 16 Jan 87 17:33:12 EST
Received: by prime.uucp (1.1/SMI-3.0DEV3)
id AA04549; Fri, 16 Jan 87 14:26:32 EST
Message-Id: <8701161926.AA04549@prime.uucp>
Received: (from user DOUG) by ENX.Prime.PDN; 16 Jan 87 13:40:19 EDT
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 16 Jan 87 13:40:20 EDT
I think that people forget the purpose of standards organizations. It is
almost never the purpose of such organizations to change existing practice.
The proposed charter of X3J13 (which will hopefully standardize Common LISP)
by Steele says explicitly that the primary purpose is to codify existing
practice. And don't forget that a major purpose of Common LISP was to
provide a !!stable!! base for development for software designers.
Although the issue of one namespace vs. two has gotten alot of discussion
(which it deserves), it would seem impossible at this time to change the
existing language. Many problems need to be solved before a one namespace
LISP with macros is acceptable and a standard is the wrong place for this.
The right place is in academia where such instability and experimentation
is both acceptable and expected.
Barry Margolin's suggestion of &functional is an attempt to extend the
language to answer the people who object to the two namespaces on the
grounds that it inhibits functional programming. It seems to do this
fairly well. One can also do this today with explicit flet/labels.
Douglas Rand
PRIME Computer
dougr@eddie.mit.edu
∂16-Jan-87 1607 wahlster@ernie.Berkeley.EDU mailing list
Received: from ERNIE.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 16:07:45 PST
Received: by ernie.Berkeley.EDU (5.57/1.16)
id AA21284; Fri, 16 Jan 87 15:53:03 PST
Date: Fri, 16 Jan 87 15:53:03 PST
From: wahlster@ernie.Berkeley.EDU (Prof. Wolfgang Wahlster)
Message-Id: <8701162353.AA21284@ernie.Berkeley.EDU>
To: common-lisp@sail.stanford.edu
Subject: mailing list
Please put me on the mailing list for the discussions
about common lisp.
Thanks
∂16-Jan-87 2059 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Jan 87 20:59:10 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45572; Fri 16-Jan-87 23:57:20 EST
Date: Fri, 16 Jan 87 23:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12270857740.BABYL@C.CS.CMU.EDU>
Message-ID: <870116235714.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 14 Jan 1987 09:34 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: Friday, 9 January 1987 17:28-EST
From: Masinter.pa at Xerox.COM
I agree with this proposal, but with corrections noted below.
How come nobody else but Fahlman has voted?
Comment: Symbolics is already using an optional argument to
GET-SETF-METHOD for something else, and it is a documented interface for
us, however I've reviewed an analysis of this made some time ago and I
think we can afford to make an incompatible change here.
Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to GET-SETF-METHOD. If the argument
is not supplied, you get the null lexical environment.
Add it to GET-SETF-METHOD-MULTIPLE-VALUE also.
Allow DEFINE-SETF-METHOD to take an ENVIRONMENT argument.
You mean &ENVIRONMENT. To be completely explicit, say that
"&ENVIRONMENT variable" can appear in the lambda-list subform
of a DEFINE-SETF-METHOD form and mention the analogy with DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Agreed.
Also add the clarification that MACROLET, FLET, and LABELS can shadow a
SETF method; in other words, a SETF method applies only when the global
binding of the name is lexically visible. (This point originally
brought up by Eric Benson 14 Dec 85). Or should this be discussed
among us as a separate issue? (I hope not!)
∂16-Jan-87 2110 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: IMPORT-UNCLEAR, Message 1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Jan 87 21:08:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45577; Sat 17-Jan-87 00:06:56 EST
Date: Sat, 17 Jan 87 00:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IMPORT-UNCLEAR, Message 1
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12270859593.BABYL@C.CS.CMU.EDU>
Message-ID: <870117000654.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 14 Jan 1987 09:44 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: Friday, 9 January 1987 20:58-EST
From: Masinter.pa at Xerox.COM
Proposal IMPORT-UNCLEAR:REWRITE:
Change the description of IMPORT to say: "if any symbol to be imported
has no home package, then IMPORT sets the home package of the symbol to
the specified package being imported to."
I agree. You say "change" but I don't see any text on either p.176 or p.186
that should be removed; it looks like this sentence would simply be added.
Clarify that INTERN does not modify a symbol's home package. Rewrite
the section avoiding the verb "intern", as it confuses everyone.
I think I agree, but for editorial things like this, I think it would be
a good idea to appoint a single individual (not necessarily a member of
this committee) to prepare the specific new language, and a list of which
specific parts of the old CLtL language are inoperative, and then we should
vote on that. As it stands I'm not sure which section we are proposing
to rewrite nor exactly what we are proposing to make it say.
Alternatively, we could decide that editorial changes in Guy's book are
not our concern, and simply say "IMPORT changes the home package of a
symbol if and only SYMBOL-PACKAGE of that symbol is NIL. For each
symbol in its first argument whose home-package is NIL, IMPORT sets
the home-package to the package specified by its second argument.
INTERN never sets the home package of an existing symbol. INTERN
always sets the home package of a symbol it newly creates." and
leave the decision of how to present those facts to someone else.
∂16-Jan-87 2144 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Jan 87 21:43:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45582; Sat 17-Jan-87 00:42:27 EST
Date: Sat, 17 Jan 87 00:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12270857798.BABYL@C.CS.CMU.EDU>
Message-ID: <870117004223.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 14 Jan 1987 09:35 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: Friday, 9 January 1987 20:43-EST
From: Masinter.pa at Xerox.COM
I approve of the general thrust of this, but it's incomplete. I think it
would be better to vote on a more complete proposal than to address each
part separately. Details below.
Issue: (Steele, p. 144) The macro function associated with a given
symbol depends on the lexical context of that symbol, and can differ
inside a MACROLET (which introduces lexical macros), or inside a FLET or
LABELS (which shadow macros). However, there is no way to account for
this lexical context in macros which know their environment (using the
&ENVIRONMENT argument) and which do their own macro expansion.
Example:
(defmacro example (form &environment environment)
(let ((macro (macro-function (car form)))
(when macro .... (funcall macro form) ...)
Aside: this example is incorrect, because the function returned
by macro-function requires two arguments (CLtL p.144). Also as a point
of esthetics it probably should use *macroexpand-hook*.
Normally, the macro-function definition reflects the interpretation of
the FORM argument to EXAMPLE. However, within a MACROLET it does not.
Classification: This is a mistake in CLtL.
Proposal MACRO-FUNCTION-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to MACRO-FUNCTION. If the argument
is not supplied, you get the null lexical environment. Otherwise, the
environment argument is used to determine the macro definition.
I agree with this, but for consistency I believe the same treatment should
be given to SPECIAL-FORM-P, to SYMBOL-FUNCTION, and to SYMBOL-VALUE.
It should be stated that SETF of MACRO-FUNCTION and SYMBOL-FUNCTION is
not permitted when two arguments are specified, even if the value of
the second argument turns out to be NIL. (Maybe I'm wrong here and
SETF should be allowed, but it should be stated that this does not
change the lexical structure of the program, it only substitutes one
binding for another existing binding in the same lexical contour,
and furthermore cannot mutate a MACROLET into a FLET or vice versa.)
I can't figure out whether CLtL intends to permit FLET/LABELS/MACROLET
to shadow global definitions of symbols as special forms. If it does
not, adding an environment argument to SPECIAL-FORM-P would be inutile.
CLtL p.57 says that anything described as a macro can be implemented as
a special form as long as a macro expander is provided; this implies
that if special forms cannot be shadowed, then macros cannot be shadowed
either. However, the discussion of this issue says that FLET and LABELS
can shadow macros, and presumably this was intended to include global
macros as well as local (MACROLET-defined) macros. It's clear that the
language is not very well-specified in this area. It would help if there
was a clearer distinction between a symbol that names an operator and the
operator object that is the definition of that symbol; I think CLtL was
a little too coy here. (An operator is a function, a macro, or a
"special form thing" (no name exists in CLtL for these; we call them
"primitive special operators", since macros are "special operators"
too.))
If no one else volunteers, I would be willing to write a proposal to
clarify this, based on what Symbolics' system does as a starting point.
It might take me 2 or 3 weeks to find the time to do it.
∂17-Jan-87 0954 DALY@IBM.COM :append keyword on compile-file
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 17 Jan 87 09:54:05 PST
Date: 17 January 1987, 11:34:43 EST
From: "Timothy P. Daly" <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <011787.113443.daly@ibm.com>
Subject: :append keyword on compile-file
Has anyone implemented a compile-file extension that would allow
the fast load file to be updated?
I would like to be able to say:
(COMPILE-FILE "foo.lisp" :APPEND "foo.bin")
with the effect that the compiler output would append its output
to the existing file rather than create a new file. The ultimate
effect of loading the FOO.BIN file should be that of loading
the original fast load file followed by the new fast load file.
This would enable me to supercede functions that exist in a fast load
file without recompiling the world.
∂17-Jan-87 2117 hpfclp!diamant@hplabs.HP.COM Re: :append keyword on compile-file
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 17 Jan 87 21:17:31 PST
Received: by hplabs.HP.COM ; Sat, 17 Jan 87 21:12:01 pst
Received: by hpfclp; Sat, 17 Jan 87 21:37:33 mst
Date: Sat, 17 Jan 87 21:37:33 mst
From: John Diamant <hpfclp!diamant@hplabs.HP.COM>
Return-Path: <hpfclp!diamant>
To: common-lisp@sail.stanford.edu
Subject: Re: :append keyword on compile-file
In-Reply-To: article <280152@hpfcjrd.HP.COM> of Sat, 17 Jan 87 19:24:23 MST
> Subject: :append keyword on compile-file
> From: "Timothy P. Daly" <hpfclp!hplabs!DALY@ibm.com>
>
> Has anyone implemented a compile-file extension that would allow
> the fast load file to be updated?
>
> I would like to be able to say:
>
> (COMPILE-FILE "foo.lisp" :APPEND "foo.bin")
>
>
> This would enable me to supercede functions that exist in a fast load
> file without recompiling the world.
While this is possible to implement, I doubt it would have the effect you
desire. It is quite common for a FASL (fast load) file to have information
like a symbol table at the beginning of the file. Appending to a FASL file
might require extending or modifying the symbol table (or other preliminary
structures in the file). Efficiently implementing what you suggest implies
a sequential ordering of the FASL file that may not exist. Thus, this option
may be implementable by everyone, but it might be vastly more efficient in
some implementations, and in fact, under certain circumstances may not gain
much at all.
John Diamant
Systems Software Operation UUCP: {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO
∂17-Jan-87 2131 hpfclp!diamant@hplabs.HP.COM preprocessor-based Common Lisps
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 17 Jan 87 21:31:42 PST
Received: by hplabs.HP.COM ; Sat, 17 Jan 87 21:31:19 pst
Received: by hpfclp; Sat, 17 Jan 87 22:28:27 mst
Date: Sat, 17 Jan 87 22:28:27 mst
From: John Diamant <hpfclp!diamant@hplabs.HP.COM>
Return-Path: <hpfclp!diamant>
To: common-lisp@sail.stanford.edu
Subject: preprocessor-based Common Lisps
I am trying to collect a comprensive list of Common Lisp implementations that
use a preprocessor, or anything remotely like one. This would mean anything
from a simple tokenizer to a full preprocessor. I would appreciate any
information which you could supply, including not only the implementation,
but also some explanation of the extent to which a preprocessor is used. I am
quite familiar with HP's implementation, as I was one of the implementors, but
I would like to hear about other implementations which use varying degrees
of preprocessor technology.
I would also like to know about any implementations that use a compile-only
strategy.
Thanks in advance,
John Diamant
Systems Software Operation UUCP: {hplabs,hpfcla}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO
∂18-Jan-87 1156 DALY@IBM.COM append option on compile-file
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 18 Jan 87 11:55:23 PST
Date: 18 January 1987, 11:54:13 EST
From: "Timothy P. Daly" <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <011887.115414.daly@ibm.com>
Subject: append option on compile-file
The ability to say
(COMPILE-FILE "foo.lisp" :APPEND "foo.bin")
can be generalized to allow access to the streams used by compile-file.
Thus I would be able to "compile-file to a stream", then "load from
the stream". Is there anything in Cltl that implies that one cannot
perform incremental updates to a FASL file or manipulating FASL
structures as streams?
Certainly there are file structures that would allow this kind of
update are well known. Most binary file libraries allow this kind
of update.
Tim Daly
DALY@IBM.COM
∂18-Jan-87 1409 hpfclp!diamant@hplabs.HP.COM Re: preprocessor-based Common Lisps
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Jan 87 14:08:55 PST
Received: by hplabs.HP.COM ; Sun, 18 Jan 87 14:08:56 pst
Received: from hpfcjrd.HP.COM by hpfclp; Sun, 18 Jan 87 15:06:47 mst
Received: by hpfcjrd; Sun, 18 Jan 87 15:06:06 mst
Date: Sun, 18 Jan 87 15:06:06 mst
From: John Diamant <hpfclp!diamant@hplabs.HP.COM>
Return-Path: <diamant@hpfcjrd>
Message-Id: <8701182206.AA06619@hpfcjrd.HP.COM>
To: Masinter.pa@Xerox.COM
Subject: Re: preprocessor-based Common Lisps
Cc: common-lisp@sail.stanford.edu
> From: Masinter.pa@Xerox.COM
>
> You don't say what you think a "pre-processor" is or does. Is READ a
> pre-processor? (I don't think so, but...)
This was sent to me as private mail, but I will respond to the entire list
because I want to get as much useful information as possible, and Larry's
point is valid.
I would not consider READ to be a preprocessor. What I am looking for are
implementations that take some of the task of the interpreter and compiler
and combine them into a common pass. Graphically:
interpreter
/
preprocessor
\
compiler
This could be as simple as a tokenizer, or as complex as everything but the
code generator in the compiler being moved to the preprocessor (but then
the interpreter would have to share the preprocessor -- otherwise, it would
just be a piece of the compiler).
Since READ is required by Common Lisp (though I suppose it doesn't actually
say anywhere that the compiler has to READ the file, I think this is obvious
that it should), this would not be anything unusual. I am looking for
"alternate evaluation strategies" as referred to by CLTL. Thus, an
compile-only implmentation would also be interesting to me.
John Diamant
Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant
Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs.HP.COM
Fort Collins, CO
∂18-Jan-87 1606 smh@mit-ems Re: preprocessor-based Common Lisps
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Jan 87 16:06:25 PST
Received: by mit-ems (5.54/4.8) id AA07193; Sun, 18 Jan 87 17:30:49 EST
Date: Sun, 18 Jan 87 17:30:49 EST
From: smh@mit-ems (Steven Haflich)
Message-Id: <8701182230.AA07193@mit-ems>
To: common-lisp@sail.stanford.edu
Subject: Re: preprocessor-based Common Lisps
Just for the record, COMPILE-FILE must read the source file with
READ because otherwise EVAL-WHEN and reader macros would have a
difficult time of it. See CLtL p.69 under EVAL-WHEN:
"... a model of how the compiler processes forms in a file
to be compiled. Successive forms are read from the file
using the function READ."
Even though this is only a "model", I take it to mean that the
actual implementation must provide the same semantics, and thus
should be indestinguishable from READ (except, perhaps, with
regard to things like (TRACE READ) ).
∂19-Jan-87 0035 edsel!bhopal!jonl@navajo.stanford.edu :append keyword on compile-file
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 19 Jan 87 00:35:02 PST
Received: by navajo.stanford.edu; Mon, 19 Jan 87 00:34:13 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA02925; Mon, 19 Jan 87 00:13:48 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA02298; Mon, 19 Jan 87 00:13:31 PST
Date: Mon, 19 Jan 87 00:13:31 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701190813.AA02298@bhopal.edsel.com>
To: navajo!DALY%ibm.com@navajo.stanford.edu
Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: "Timothy P. Daly"'s message of 17 January 1987, 11:34:43 EST
Subject: :append keyword on compile-file
PDP10 MacLisp structured its "fasl" file format so that the loader
could simply read one "fasl group" in a file, and then read the next
one, and so on. That way, pre-existing fasl files could be simply
concatenated, and one call to the LOAD function would get them all
(in sequence). Of course, this implies a certain independence among
the "groups". The compiler could also produce concatenated fasl files
from a multiple-source-file compilation request.
Version 2 of Lucid's system has such a capabililty (in the fasl loader).
We have used it internally as a means of batching together some related
compiled files, and for "tacking on" patch files. However, I don't know
just how or when this will be made available for customer use.
-- JonL --
∂19-Jan-87 1218 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: preprocessor-based Common Lisps
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 Jan 87 12:18:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 46409; Mon 19-Jan-87 15:11:58 EST
Date: Mon, 19 Jan 87 15:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: preprocessor-based Common Lisps
To: John Diamant <hpfclp!diamant@hplabs.HP.COM>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8701182206.AA06619@hpfcjrd.HP.COM>
Message-ID: <870119150910.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Is the fact that the DEFUN special form in Symbolics Common Lisp
fully macro-expands the body before storing the interpreted function
as the definition of its name the sort of thing you are looking for?
This is not at all at the token-parsing level you seemed to be talking
about at first, but seems to fit some of what you said in your latest
message.
∂19-Jan-87 1650 Masinter.pa@Xerox.COM discussion: macro environments
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Jan 87 16:50:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 JAN 87 16:42:05 PST
Date: 19 Jan 87 16:45 PST
From: Masinter.pa@Xerox.COM
Subject: discussion: macro environments
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870119-164205-1133@Xerox>
I've not gotten any private messages on any of the topics; that is,
there've been no replies other than what's gone to cl-cleanup.
If we agree that several issues should be combined and considered as a
whole, so much the better.
One reason for separating out GET-SETF-METHOD-ENVIRONMENT and
MACRO-FUNCTION-ENVIRONMENT is that, while MACRO-FUNCTION currently works
as specified (i.e., the language in CLtL clearly states that it only
gets the *global* definition, while MACROEXPAND-1 and MACROEXPAND
themselves take environments), the specification for GET-SETF-METHOD is
currently inconsistent, e.g., the example on p 107 is incorrect because
it does not account for the environment of the SETF.
To put it another way, the cost of not adding the feature is different
for each of the proposals.
To put SYMBOL-FUNCTION and SYMBOL-VALUE into the same context is to
confound the lexical environments used in the interpreter (as passed,
e.g., by evalhook) and the lexical environments used by macro expansion
(as passed, e.g., to the &environment arguments of macros.) While both
of these (unspecified) pointers are "lexical environments", their use,
origin, and presumably internal structure are potentially radically
different.
I've more comments, but it will be late this week before I can send
them, and I thought I should get these notes out sooner.
∂20-Jan-87 0331 @SAIL.STANFORD.EDU:REM@IMSSS Quoted structure not necessarily constant in my opinion, fix CLtL
Received: from SAIL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jan 87 03:30:52 PST
Date: 1987 January 19 21:11:50 PST (=GMT-8hr)
From: Robert Elton Maas <REM%IMSSS@SU-AI.ARPA>
To:Common-LISP@SU-AI.ARPA
CC:Fahlman@C.CS.CMU.EDU,edsel!babel!eb@navajo.stanford.edu
Subject:Quoted structure not necessarily constant in my opinion, fix CLtL
<F> Date: Tue, 6 Jan 1987 19:29 EST
<F> From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
<F> Subject: Destructive operations
<F> In my view, when a constant appears in code, the compiler is free to
<F> store this in read-only space or do other strange things that depend on
<F> the constantness of the constant.
This discussion isn't about constants, but about quoted structure. How
does a compiler determine whether quoted structure is intended to be
constant or merely initial (default) value? Where quoted structure
appears as second argument to MEMQ or MEMBER or as either argument to
EQ or EQUAL et al, it is obviously not changeable hence constant. But
where quoted structure appears as second argument to SETQ at toplevel
(not inside body of any function) it is often just an initial value.
(Where it appears as second argument to SETQ within a function that
might be loaded once but executed multiple times, it is probably poor
programming practice and should be flagged by compiler, since on the
one hand it can't be proved unchangeable, yet if it is ever
destructively changed the semantics of the function are changed out
from under it.) Perhaps only unambiguous cases should be accepted by
the language spec, that is global SETQs are assumed to be
default/initial values wile places that can't possibly be changed are
assmed to be constant, and all other use should "be an error".
<F> ... I found nothing about other constants, such as '(a b c), that
<F> might appear in the body of the code. Still, I think that we must
<F> allow the compiler to assume that these things will not be altered
<F> destructively.
I think assuming '(a b c) is a constant is wrong, except in special
cases such as I outlined above.
<F> You can always store the list in a variable if you want
<F> it to be malleable.
Variables don't "hold" lists the way they do in, say, FORTRAN.
Variables hold pointers to the list, which may be shared among several
pointers. In the case above of '(a b c) somewhere, copying the pointer
to a variable doesn't solve the problem if the original data and hence
the pointed-at data is in readonly memory. You must actually copy the
whole data structure recursively by COPY or COPY-WHOLE or somesuch
function, but then you end up with the original data sitting in
readonly memory inaccessible yet permanently occupying memory. The
compiler should arrange that the original of the data gets loaded into
the heap (collectable memory) in the first place to avoid occupying
readonly space with data that won't ever be referenced after loading
the file.
<F> A subcommittee of X3J13 has been set up to formulate recommendations
<F> on how to fix this. This is one of the issues that they should address.
I hope my points about readonly (constant) vs. initial-value will be
raised by somebody attending.
<EB> Date: Tue, 6 Jan 87 16:49:13 pst
<EB> From: edsel!babel!eb@navajo.stanford.edu (Eric Benson)
<EB> Subject: Destructive operations
<EB> On p.78 of CLtL, in the description of the function EQ, is the
<EB> following paragraph:
<EB> ``An additional problem with EQ is that the implementation is permitted
<EB> to "collapse" constants (or portions thereof) appearing in code to be
<EB> compiled if they are EQUAL. An object is considered to be a constant
<EB> in code to be compiled if it is a self-evaluating form or is contained
<EB> in a QUOTE form.
I believe strongly this is a design mistake, innerds of QUOTE form can
be initial values as well as constants, depending on context, as per
my remarks earlier. Is it too late to fix this in the spec? But if
something is truly constant, then I agree any EQUAL parts should be
foldable with each other within a single constant such as '(A (B) C (B) B)
or between constants.
<EB> Because the compiler is permitted to share structure with constants in
<EB> compiled code, it follows that modifying such a constant is illegal.
If they are modified, then perhaps they weren't supposed to be
constants in the first place, the compiler jumped to a false conclusion.
<EB> Date: Wed, 7 Jan 87 11:38:23 pst
<EB> From: edsel!babel!eb@navajo.stanford.edu (Eric Benson)
<EB> Subject: Destructive operations
<EB> Right you are. I was assuming too much. Just because something may
<EB> have horrible consequences doesn't necessarily make it illegal.
<EB> Modifying constants in compiled code has the same legal status as
<EB> modifying the SYMBOL-NAME string of a symbol. ``It is an extremely
<EB> bad idea to modify'' a constant in compiled code.
It's also an extremely bad idea for a compiler designer to assume
anyone who quotes any structure intends it to be readonly (constant),
unless the programmer also declares it to be constant somehow, or it
is obvious from the code it must be constant (but then the question is
moot).
<EB> For similar reasons, it is a bad idea to modify any object which is
<EB> used as a key in an EQUAL hash table (this problem is unfortunately
<EB> not mentioned in CLtL).
Putting a key in an EQUAL hash table is an obvious case where the
programmer is stamping the structure readonly, and compiler is
warranted in optimizing accordingly. I agree CLtL should warn about this.
∂20-Jan-87 1305 sandra%utah-orion@utah-cs.arpa *print-circle*
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 20 Jan 87 13:03:49 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA25591; Tue, 20 Jan 87 14:06:05 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA09740; Tue, 20 Jan 87 14:06:00 MST
Date: Tue, 20 Jan 87 14:06:00 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8701202106.AA09740@utah-orion.ARPA>
Subject: *print-circle*
To: common-lisp@sail.stanford.edu
Is there a compelling reason why *print-circle* is not required to identify
shared substructures, as well as circular structures? The "obvious" (to me)
implementation will detect both. Being able to write out a complex, linked
structure with the guarantee that its topology will be preserved when it
is read back in again seems like a very useful thing. I'd be glad to share
my code to do this if there is sufficient demand for it.
-Sandra
-------
∂20-Jan-87 1451 vanroggen%bach.DEC@decwrl.DEC.COM Looking for Lisps...
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 20 Jan 87 14:48:47 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA09113; Tue, 20 Jan 87 14:49:06 PST
Message-Id: <8701202249.AA09113@decwrl.dec.com>
Date: Tuesday, 20 Jan 1987 14:48:29-PST
From: vanroggen%bach.DEC@decwrl.DEC.COM
To: common-lisp@sail.stanford.edu, vanroggen%bach.DEC@decwrl.DEC.COM
Subject: Looking for Lisps...
As part of a feature of the LISP POINTERS newsletter, we'd like to collect
descriptions of all currently available Lisp implementations.
Any kind of Lisp is acceptable; it doesn't have to be Common Lisp or Scheme or
Interlisp or MacLisp. It doesn't have to be a commercially supported product
either; it can be free with no warranties whatsoever.
If you're working on an implementation, and you're willing to describe it
for everyone's benefit, send us at least the following information:
Implementation Name
Implemented to which standard (if any)
Features (if no standard; see the suggested list of issues below)
Additional Features (if implemented according to a standard)
Missing Features (if implemented according to a standard)
Current version/availability/prices
Support (if supported, by whom; sources available?)
Machine(s)
Operating System(s)
Source or Contact
Any other comments
Submitter's name, address, and net-address
Some features you might want to comment on include:
Predefined data types
Name spaces and scopes and extents
Control structures (e.g., special forms, non-local goto's, multiple
values, multiple stacks, tasking, multi-processor support)
Typing and declarations
Garbage collection
I/O functions
Compiler
Object-oriented support
Graphics and windowing support
Programming tools (e.g., graphics packages, editor interaction,
system maintenance)
Interaction with other languages
AI-oriented tools (e.g., pattern matching, rules, database support,
natural language interface)
Any other interesting features
Send this information to:
Walter van Roggen
Net address: VANROGGEN%BACH.DEC@DECWRL.DEC.COM
Mail address: HLO2-3/E9, 77 Reed Rd, Hudson MA, 01749, USA
∂21-Jan-87 0738 Pase.CCS@DOCKMASTER.ARPA Mailing List
Received: from DOCKMASTER.ARPA by SAIL.STANFORD.EDU with TCP; 21 Jan 87 07:38:21 PST
Date: Wed, 21 Jan 87 10:35 EST
From: Bill Pase <Pase@DOCKMASTER.ARPA>
Subject: Mailing List
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870121153506.840831@DOCKMASTER.ARPA>
Could I
∂21-Jan-87 1353 hpfclp!diamant@hplabs.HP.COM Re: preprocessor-based Common Lisps
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 21 Jan 87 13:50:31 PST
Received: by hplabs.HP.COM ; Wed, 21 Jan 87 13:50:22 pst
Received: by hpfclp; Wed, 21 Jan 87 10:18:27 mst
Date: Wed, 21 Jan 87 10:18:27 mst
From: John Diamant <hpfclp!diamant@hplabs.HP.COM>
Return-Path: <hpfclp!diamant>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Subject: Re: preprocessor-based Common Lisps
Cc: common-lisp@sail.stanford.edu
> Is the fact that the DEFUN special form in Symbolics Common Lisp
> fully macro-expands the body before storing the interpreted function
> as the definition of its name the sort of thing you are looking for?
Yes, I would be interested in that type of preprocessing. I think my second
note gave a more accurate description of what I was looking for than my first
one. Specifically, I would like to know how the interpreted function is
stored (internal representation or simply macro-expanded source code), and
if the original source code is kept around for debugging purposes). I have
Symbolics manuals (Release 5.0) in case you could give me a pointer on this
if it is discussed in the manual. Otherwise, I would appreciate any
information you could supply about the extend to which preprocessing is used.
John Diamant
diamant%hpfclp@hplabs.HP.COM
∂21-Jan-87 1411 FAHLMAN@C.CS.CMU.EDU preprocessor-based Common Lisps
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Jan 87 14:09:48 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 21 Jan 87 17:08:57-EST
Date: Wed, 21 Jan 1987 17:08 EST
Message-ID: <FAHLMAN.12272775404.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: John Diamant <hpfclp!diamant@HPLABS.HP.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: preprocessor-based Common Lisps
In-reply-to: Msg of 21 Jan 1987 12:18-EST from John Diamant <hpfclp!diamant at hplabs.HP.COM>
In the majority of Common Lisp systems that I know of, DEFUN inserts the
named block around the body of the lambda form before saving it away.
So in this minimal sense, almost everyone does some pre-processing in
the interpreter.
A lot of systems save macro-expansions inline (more or less) after the
first expansion occurs. This is usually a feature that you can turn on
and off, and in the better systems you can undo such actions if the
macro is redefined. I think that systems that expand macros or do other
optimizations at DEFUN time are in the minority, however.
-- Scott
∂21-Jan-87 1915 Moon@STONY-BROOK.SCRC.Symbolics.COM *print-circle*
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Jan 87 19:15:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48727; Wed 21-Jan-87 22:15:25 EST
Date: Wed, 21 Jan 87 22:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *print-circle*
To: Sandra J Loosemore <sandra%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8701202106.AA09740@utah-orion.ARPA>
Message-ID: <870121221249.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 20 Jan 87 14:06:00 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Is there a compelling reason why *print-circle* is not required to identify
shared substructures, as well as circular structures? The "obvious" (to me)
implementation will detect both.
Circular structures can be identified with a little less overhead, since the
amount of state needed at any moment is proportional to the depth of the
structure rather than to the total size of the structure. Also the state
has the right lifetime to be stored in a stack, so a non-consing implementation
can be used easily. Neither of these strikes me as compelling!
Being able to write out a complex, linked
structure with the guarantee that its topology will be preserved when it
is read back in again seems like a very useful thing. I'd be glad to share
my code to do this if there is sufficient demand for it.
Symbolics' implementation of *print-circle* looks for shared substructures, and
it wouldn't surprise me if a lot of other implementations also do so. It
seems like a good idea. I could imagine a user demand for separate control
of circularity detecting and sharing detection; one side-effect of full
shared substructure detection that surprised me when I first saw it was
the result of
(let ((*print-circle* t))
(print (macroexpand-all '(dolist (x y)
(dolist (w x)
(print w))))))
because there is some substructure shared between the two expansions of
the dolist macro; in our case the list (NIL) happens to be shared
and so the second occurrence turns into a #1#.
∂22-Jan-87 0553 GZ%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU symbol-function of non-functions
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 05:53:30 PST
Date: Thu 22 Jan 87 08:52:25-EST
From: "Gail Zacharias" <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: symbol-function of non-functions
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12272947186.15.GZ@OZ.AI.MIT.EDU>
The manual seems to imply that fboundp is required to return non-nil
for macros and special forms, while symbol-function is merely allowed
to do so (".. function or MAY be an object representing a special form
or macro.."). Am I reading that right?
In any case, it seem to me that these definitions make it impossible
to tell for sure whether a symbol is a valid argument to APPLY/FUNCALL.
I.e. in implementations which do not keep macros in the function cell,
so that macro-function being true does not imply non-applicability of the
symbol, there is no CL way to find out if there is an applicable definition
regardless of whether there is or isn't a macro definition.
Why not require fboundp be true if and only if there is an applicable
definition. You could still say (or (macro-function x) (special-form-p x)
(fboundp x)) if you really want to include all possibilities, while there is no
way to implement the more restrictive fboundp in terms of what's currently
documented.
-------
∂22-Jan-87 0744 FAHLMAN@C.CS.CMU.EDU symbol-function of non-functions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 07:44:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 22 Jan 87 10:44:08-EST
Date: Thu, 22 Jan 1987 10:44 EST
Message-ID: <FAHLMAN.12272967510.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gail Zacharias <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: symbol-function of non-functions
In-reply-to: Msg of 22 Jan 1987 08:52-EST from Gail Zacharias <GZ%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
We definitely need to clean up the description of the function data-type
and related functions so that people can tell exactly what they have,
whether it is applicable, etc. I don't think that FBOUNDP is the right
place to do this, however -- that wants to be fast.
-- Scott
∂22-Jan-87 0916 sandra%utah-orion@utah-cs.arpa Re: *print-circle*
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jan 87 09:16:13 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA06156; Thu, 22 Jan 87 10:18:32 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA19008; Thu, 22 Jan 87 10:18:26 MST
Date: Thu, 22 Jan 87 10:18:26 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8701221718.AA19008@utah-orion.ARPA>
Subject: Re: *print-circle*
To: David A. Moon <Moon@scrc-stony-brook.arpa>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Jan 87 22:12 EST
Date: Wed, 21 Jan 87 22:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Symbolics' implementation of *print-circle* looks for shared
substructures, and it wouldn't surprise me if a lot of other
implementations also do so. It seems like a good idea.
This is the sort of information I was looking for. If this is indeed the
common practice, and we all agree it is a good idea, then it should be
standardized. So far I have had a number of requests for my code and
one reply from a person who thought this behavior already was specified
in the manual. I have yet to hear any negative comments.
I could imagine a user demand for separate control
of circularity detecting and sharing detection....
So could I, but I suspect that it would be harder to get everyone to agree
on introducing a separate control mechanism than it would for us to agree to
make *print-circle* do this, especially if *print-circle* already behaves
this way in many implementations.
I might add that an additional reason to provide a standardized way to
print shared structures is that it's not possible for an ordinary user
to write a general purpose routine to do this without knowing how to get
at the internal representation of structures generated via defstruct.
-Sandra
-------
∂22-Jan-87 1034 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: *print-circle*
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jan 87 10:33:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49267; Thu 22-Jan-87 13:34:34 EST
Date: Thu, 22 Jan 87 13:31 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: *print-circle*
To: cl-cleanup@sail.stanford.edu
References: <8701221718.AA19008@utah-orion.ARPA>
Message-ID: <870122133158.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Is this in our bailiwick?
Date: Thu, 22 Jan 87 10:18:26 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Date: Wed, 21 Jan 87 22:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Symbolics' implementation of *print-circle* looks for shared
substructures, and it wouldn't surprise me if a lot of other
implementations also do so. It seems like a good idea.
This is the sort of information I was looking for. If this is indeed the
common practice, and we all agree it is a good idea, then it should be
standardized. So far I have had a number of requests for my code and
one reply from a person who thought this behavior already was specified
in the manual. I have yet to hear any negative comments.
I could imagine a user demand for separate control
of circularity detecting and sharing detection....
So could I, but I suspect that it would be harder to get everyone to agree
on introducing a separate control mechanism than it would for us to agree to
make *print-circle* do this, especially if *print-circle* already behaves
this way in many implementations.
I might add that an additional reason to provide a standardized way to
print shared structures is that it's not possible for an ordinary user
to write a general purpose routine to do this without knowing how to get
at the internal representation of structures generated via defstruct.
-Sandra
-------
∂22-Jan-87 1039 FAHLMAN@C.CS.CMU.EDU *print-circle*
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 10:39:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 22 Jan 87 13:39:19-EST
Date: Thu, 22 Jan 1987 13:39 EST
Message-ID: <FAHLMAN.12272999385.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: *print-circle*
In-reply-to: Msg of 22 Jan 1987 13:31-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I think so, but not high on the queue. Real problems need to be dealt
with before random improvements.
It's pretty quiet out there... I have some responses to Moon's comments
on the first three proposals, but I thought I'd wait until some of the
rest of the committee had said something. Guess that's not a good
strategy with this group.
-- Scott
∂22-Jan-87 1338 MURRAY%cs.umass.edu@RELAY.CS.NET *print-circle*
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 22 Jan 87 13:38:24 PST
Received: from cs.umass.edu by csnet-relay.csnet id ab14260; 22 Jan 87 16:20 EST
Date: Thu, 22 Jan 87 15:42 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SU-AI.ARPA
Subject: *print-circle*
X-VMS-To: CSNET%"common-lisp@su-ai.ARPA"
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
.. Is there a compelling reason why *print-circle* is not required
to identify shared substructures, as well as circular structures? ..
.. I could imagine a user demand for separate control
of circularity detecting and sharing detection; ..
I agree that it should be two different switches. *Print-circle*
should only endeavor to find circularity, with perhaps *print-shared*
to do the full checking. I think a lot of cases of using *print-circle*
are to make sure you don't get infinite printing, where you don't really
care about sharing. In these cases, the #1#'s seem "spurious", and
actually make the data hard to read.
Kelly Murray
∂22-Jan-87 1416 Mailer@XX.LCS.MIT.EDU Re: symbol-function of non-functions
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 14:15:55 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Jan 87 17:15-EST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 25868; 22 Jan 87 17:16:37-EST
Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 52241; Thu 22-Jan-87 16:58:52-EST
Date: Thu, 22 Jan 87 16:56 EDT
From: Randy@a
To: common-lisp@SAIL.STANFORD.EDU
Subject: Re: symbol-function of non-functions
Actually, I've always wondered why SYMBOL-FUNCTION has to signal
an error if the symbol does not have anything in its function cell.
If it is in an attempt to be parallel to SYMBOL-VALUE, then what
about SYMBOL-PLIST and SYMBOL-PACKAGE? SYMBOL-VALUE has to be special
since NIL is an allowable value for a symbol to have, but NIL in
a function cell would mean that there is no function. Does all of
this mean that it is incorrect to (SETF (SYMBOL-FUNCTION 'FOO) NIL)
and that one *has* to use FMAKUNBOUND instead?
Random
∂22-Jan-87 1527 Masinter.pa@Xerox.COM adjusting displaced arrays
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Jan 87 15:19:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JAN 87 15:10:10 PST
Date: 22 Jan 87 15:11 PST
From: Masinter.pa@Xerox.COM
Subject: adjusting displaced arrays
To: cl-cleanup@sail.stanford.edu
Message-ID: <870122-151010-1280@Xerox>
I'm having trouble summarizing the issues having to do with adjusting
displacable arrays. Does anyone want to volunteer to build the summary?
There was a lot of discussion of the issue, but there doesn't seem to be
a conclusive layout of the alternatives, etc.
∂22-Jan-87 1530 Moon@STONY-BROOK.SCRC.Symbolics.COM symbol-function of non-functions
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jan 87 15:27:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 49437; Thu 22-Jan-87 16:16:17 EST
Date: Thu, 22 Jan 87 16:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: symbol-function of non-functions
To: Gail Zacharias <GZ%OZ.AI.MIT.EDU@MIT-MC.ARPA>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <12272947186.15.GZ@OZ.AI.MIT.EDU>
Message-ID: <870122161341.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu 22 Jan 87 08:52:25-EST
From: "Gail Zacharias" <GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
The manual seems to imply that fboundp is required to return non-nil
for macros and special forms, while symbol-function is merely allowed
to do so (".. function or MAY be an object representing a special form
or macro.."). Am I reading that right?
In any case, it seem to me that these definitions make it impossible
to tell for sure whether a symbol is a valid argument to APPLY/FUNCALL.
I.e. in implementations which do not keep macros in the function cell,
so that macro-function being true does not imply non-applicability of the
symbol, there is no CL way to find out if there is an applicable definition
regardless of whether there is or isn't a macro definition.
Why not require fboundp be true if and only if there is an applicable
definition. You could still say (or (macro-function x) (special-form-p x)
(fboundp x)) if you really want to include all possibilities, while there is no
way to implement the more restrictive fboundp in terms of what's currently
documented.
You seem to be assuming that Common Lisp allows a symbol to be
simultaneously a function and a macro. It doesn't. It only allows a
symbol to be simultaneously a macro and a special form. Thus
macro-function being true really does imply non-applicability.
I think fboundp is supposed to mean: is this symbol globally defined as
any one of a function, a macro, or a special form, i.e. does this symbol
mean something in the car of a form in the global lexical environment?
Note that I didn't say anything about implementation in terms of
function cells, alists, or anything else.
∂22-Jan-87 1532 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Pushing defmacro hard: destructured &KEY bindings
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 22 Jan 87 15:32:11 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48658; Thu 22-Jan-87 17:44:14 EST
Date: Thu, 22 Jan 87 17:43 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Pushing defmacro hard: destructured &KEY bindings
To: Common-Lisp@SU-AI.ARPA
Message-ID: <870122174353.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
CLtL pages 149-151 mentions destructuring within lambda list keywords
for defmacro, but don't give enough examples for users to know what is
expected to work and what isn't. Specifically, it does give examples of
destructuring &OPTIONAL, but doesn't say &REST may not be destructured
(it doesn't at first glance make much sense, but program writing
programs may generate it, and it may be a good way to do some further
destructuring) and it is silent on &KEY. For example, is the following
legal?
(defmacro funny (&key
((:two-elements (x1 x2)) '(two-1 two-2))
((:three-elements (y1 y2 y3)) '(three-1 three-2 three-3))
((:two-or-three (z1 z2 &optional (z3 'zee-three))) '(sis boom bah)))
(list x1 x2 y1 y2 y3 z1 z2 z3))
(funny :three-elements (foo bar baz)
:two-elements (Common Lisp)
:two-or-three (tea coffee))
==> (Common Lisp foo bar baz tea coffee zee-three)
And is this legal?
(defmacro bone (a b &optional c &rest (&whole d &optional e f g &rest h))
(list a b c d e f g h))
∂22-Jan-87 1744 mincy@think.com Pushing defmacro hard: destructured &KEY bindings
Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jan 87 17:41:13 PST
Received: from Godot.Think.COM by zarathustra.think.com; Thu, 22 Jan 87 20:41:39 EST
Received: from heidegger by Godot.Think.COM via CHAOS; Thu, 22 Jan 87 20:41:24 EST
Date: Thu, 22 Jan 87 20:42 EST
From: Jeff Mincy <mincy@think.com>
Subject: Pushing defmacro hard: destructured &KEY bindings
To: DCP@quabbin.scrc.symbolics.com, Common-Lisp@sail.stanford.edu
In-Reply-To: <870122174353.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Message-Id: <870122204217.3.MINCY@HEIDEGGER.THINK.COM>
Date: Thu, 22 Jan 87 17:43 EST
From: David C. Plummer <DCP@quabbin.scrc.symbolics.com>
Subject: Pushing defmacro hard: destructured &KEY bindings
CLtL pages 149-151 mentions destructuring within lambda list keywords
for defmacro, but don't give enough examples for users to know what is
expected to work and what isn't. Specifically, it does give examples of
destructuring &OPTIONAL, but doesn't say &REST may not be destructured
(it doesn't at first glance make much sense, but program writing
programs may generate it, and it may be a good way to do some further
destructuring) and it is silent on &KEY. For example, is the following
legal?
p146 CLtL ... known as destructuring.
"Anywhere in the lambda-list where a parameter name may
appear, and where ordinary lambda-list syntax (5.2.2) does not otherwise
allow a list, a lambda-list may appear in place of the parameter name."
So I'd interpret that to mean any of the following "var"s in
lambda-lists may be replaced with a lambda-list.
( {var}*
&optional (var [initform [svar]])
&rest var
&key ((key var) [initform [svar]]).
)
I'd say your examples are valid.
-jeff
∂22-Jan-87 2207 @REAGAN.AI.MIT.EDU:cfry@OZ.AI.MIT.EDU fsymeval before arg-eval?
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jan 87 22:06:49 PST
Received: from INTERCEPTOR.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 19136; Fri 23-Jan-87 01:08:03 EST
Date: Fri, 23 Jan 87 01:07 EST
From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
Subject: fsymeval before arg-eval?
To: Common-Lisp@SU-AI.ARPA
Message-ID: <870123010757.0.CFRY@INTERCEPTOR.AI.MIT.EDU>
When eval gets a call to a function,
is the definition that is used gotten out of the symbol
before the args are evaled or afterwords?
Since eval has to first figure out if the car of the form is
a macro, special-form or regular function before it can know what
to do with the args, it makes sense that it gets the def before
arg evaluation. But I haven't found a reference to this in the spec.
A case where this would matter is:
(defun foo (x) 1)
(foo (defun foo (x) 2)) => 1 or 2 ?
A particularly pathological case would be:
(defun foo (x) 1)
(foo (defmacro foo (x) 2))
∂23-Jan-87 0633 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: symbol-function of non-functions
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 23 Jan 87 06:33:20 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48803; Fri 23-Jan-87 09:22:18 EST
Date: Fri, 23 Jan 87 09:21 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: symbol-function of non-functions
To: Randy@ALLEGHENY.SCRC.Symbolics.COM, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 22 Jan 87 15:56 EST from Randy@ALLEGHENY.SCRC.Symbolics.COM
Message-ID: <870123092151.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Thu, 22 Jan 87 16:56 EDT
From: Randy@a
Actually, I've always wondered why SYMBOL-FUNCTION has to signal
an error if the symbol does not have anything in its function cell.
If it is in an attempt to be parallel to SYMBOL-VALUE, then what
about SYMBOL-PLIST and SYMBOL-PACKAGE? SYMBOL-VALUE has to be special
since NIL is an allowable value for a symbol to have, but NIL in
a function cell would mean that there is no function.
Not at all. It means that a further indirection needs to be taken since
NIL is itself a symbol. The indirection looks for the functional value
of NIL, which is presumably unbound, and will then generate an error.
Does all of
this mean that it is incorrect to (SETF (SYMBOL-FUNCTION 'FOO) NIL)
and that one *has* to use FMAKUNBOUND instead?
You can do (SETF (SYMBOL-FUNCTION 'FOO) NIL) and then (FOO) will try to
invoke NIL as a function because of the indirection stated above, and
the fboundness of NIL will determine what will happen. So... to make a
symbol globally funbound, you do have to use FMAKUNOUND.
∂23-Jan-87 0713 nelson%bach.DEC@decwrl.DEC.COM functionp/fboundp
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 23 Jan 87 07:13:00 PST
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA23658; Fri, 23 Jan 87 07:13:11 PST
Message-Id: <8701231513.AA23658@decwrl.dec.com>
Date: Friday, 23 Jan 1987 07:09:49-PST
From: nelson%bach.DEC@decwrl.DEC.COM (Beryl Elaine Nelson)
To: common-lisp@sail.stanford.edu, gz%oz.ai.mit.edu@xx.lcs.mit.edu
Subject: functionp/fboundp
From: RHEA::DECWRL::""Gail Zacharias" GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU" 22-JAN-1987 12:37
To: common-lisp@SAIL.STANFORD.EDU
Subj: symbol-function of non-functions
The manual seems to imply that fboundp is required to return non-nil
for macros and special forms, while symbol-function is merely allowed
to do so (".. function or MAY be an object representing a special form
or macro.."). Am I reading that right?
In any case, it seem to me that these definitions make it impossible
to tell for sure whether a symbol is a valid argument to APPLY/FUNCALL.
I.e. in implementations which do not keep macros in the function cell,
so that macro-function being true does not imply non-applicability of the
symbol, there is no CL way to find out if there is an applicable definition
regardless of whether there is or isn't a macro definition.
In VAX LISP, the function FUNCTIONP returns true if the argument can be
used in a call to FUNCALL or to APPLY. Unfortunately, notes sent to this
mailing list have indicated that in other implementations FUNCTIONP returns
true for all symbols, regardless of the current symbol-function cell contents.
In those cases you could write your own version of functionp to say
(defun apply-argument-p (x)
(if (symbolp x)
(and (fboundp x)
(not (macro-function x))
(not (special-form-p x)))
(functionp x)))
Why not require fboundp be true if and only if there is an applicable
definition. You could still say (or (macro-function x) (special-form-p x)
(fboundp x)) if you really want to include all possibilities, while there is no
way to implement the more restrictive fboundp in terms of what's currently
documented.
You can also now determine what you want by using the form written above.
Beryl Nelson
nelson%bach@decwrl.dec.com
∂23-Jan-87 0753 DLW@RIVERSIDE.SCRC.Symbolics.COM fsymeval before arg-eval?
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 07:50:57 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 95561; Fri 23-Jan-87 10:49:37 EST
Date: Fri, 23 Jan 87 10:47 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: fsymeval before arg-eval?
To: cfry@OZ.AI.MIT.EDU, Common-Lisp@SU-AI.ARPA
In-Reply-To: <870123010757.0.CFRY@INTERCEPTOR.AI.MIT.EDU>
Message-ID: <870123104759.6.DLW@CHICOPEE.SCRC.Symbolics.COM>
It has to get the definition out of the symbol first.
(Otherwise, how could it tell whether the form is a funtion call, or a
macro form?)
You're right that the definition of the language should clearly specify
that the function to be applied is the symbol-function contents before
evaluation of the arguments. That is, it is not correct to re-fetch the
contents of the cell after those evaluations.
∂23-Jan-87 0822 preece%mycroft@gswd-vms.ARPA functionp/fboundp
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 08:22:29 PST
Received: from mycroft.GSD (mycroft.ARPA) by gswd-vms.ARPA (5.52/)
Message-Id: <8701231621.AA11025@gswd-vms.ARPA>
Date: Fri, 23 Jan 87 10:19:15 CST
From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@sail.stanford.edu
Subject: functionp/fboundp
nelson%bach.DEC@decwrl.DEC.COM (Beryl Elaine Nelson):
> ... Unfortunately, notes sent to this
> mailing list have indicated that in other implementations FUNCTIONP returns
> true for all symbols, regardless of the current symbol-function cell
> contents.
----------
Since CLtL says "FBOUNDP is always true of symbols", it's hard to
see how we could do anything else... (I agree, though, that the
suggested function would be useful).
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@gswd-vms
∂23-Jan-87 0906 preece%mycroft@gswd-vms.ARPA Re: functionp/fboundp
Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 09:06:22 PST
Received: from mycroft.GSD (mycroft.ARPA) by gswd-vms.ARPA (5.52/)
Message-Id: <8701231705.AA11090@gswd-vms.ARPA>
Date: Fri, 23 Jan 87 11:03:04 CST
From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece)
To: COMMON-LISP@sail.stanford.edu
Subject: Re: functionp/fboundp
Needless to say, when I typed:
Since CLtL says "FBOUNDP is always true of symbols", it's hard to
see how we could do anything else... (I agree, though, that the
suggested function would be useful).
the "FBOUNDP" should have been "FUNCTIONP"...
--
scott preece
gould/csd - urbana
uucp: ihnp4!uiucdcs!ccvaxa!preece
arpa: preece@gswd-vms
∂23-Jan-87 1125 sandra%utah-orion@utah-cs.arpa another question about defmacro lambda lists
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 11:25:10 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA10694; Fri, 23 Jan 87 12:27:28 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA25049; Fri, 23 Jan 87 12:27:25 MST
Date: Fri, 23 Jan 87 12:27:25 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8701231927.AA25049@utah-orion.ARPA>
Subject: another question about defmacro lambda lists
To: common-lisp@sail.stanford.edu
Does it make sense for nested lambda lists in a defmacro to contain things
like &environment? CLtL does not say whether the non-top-level lambda lists
should be ordinary function lambda lists or whether they can use the extended
syntax.
-Sandra
-------
∂23-Jan-87 1215 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM another question about defmacro lambda lists
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 23 Jan 87 12:13:19 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 48964; Fri 23-Jan-87 15:11:19 EST
Date: Fri, 23 Jan 87 15:10 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: another question about defmacro lambda lists
To: Sandra J Loosemore <sandra%utah-orion@UTAH-CS.ARPA>,
common-lisp@sail.stanford.edu
In-Reply-To: <8701231927.AA25049@utah-orion.ARPA>
Message-ID: <870123151054.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Fri, 23 Jan 87 12:27:25 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Does it make sense for nested lambda lists in a defmacro to contain things
like &environment?
No, it doesn't make sense. There is only one environment (the one in
which the macro is being expanded in). (Nor can it be destructured.)
CLtL does not say whether the non-top-level lambda lists
should be ordinary function lambda lists or whether they can use the extended
syntax.
I almost couldn't find &environment because of a "publishing" glitch!!
The last paragraph on page 145 is supposed to have &environment next to
it, but doesn't. Indeed, the spec should be explicit about what may
appear in nested lambda lists.
∂23-Jan-87 1435 Moon@STONY-BROOK.SCRC.Symbolics.COM another question about defmacro lambda lists
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jan 87 12:35:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50324; Fri 23-Jan-87 15:08:23 EST
Date: Fri, 23 Jan 87 15:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: another question about defmacro lambda lists
To: Sandra J Loosemore <sandra%utah-orion@UTAH-CS.ARPA>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8701231927.AA25049@utah-orion.ARPA>
Message-ID: <870123150538.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 23 Jan 87 12:27:25 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Does it make sense for nested lambda lists in a defmacro to contain things
like &environment? CLtL does not say whether the non-top-level lambda lists
should be ordinary function lambda lists or whether they can use the extended
syntax.
They certainly need to allow destructuring; it wouldn't make sense to have only
a single level of destructuring. I don't think &whole and &environment make
sense any place other than at the top level, though.
∂23-Jan-87 1509 edsel!bhopal!jonl@navajo.stanford.edu fsymeval before arg-eval?
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jan 87 15:08:21 PST
Received: by navajo.stanford.edu; Fri, 23 Jan 87 15:07:06 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA06525; Fri, 23 Jan 87 13:50:23 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA10259; Fri, 23 Jan 87 13:49:53 PST
Date: Fri, 23 Jan 87 13:49:53 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701232149.AA10259@bhopal.edsel.com>
To: navajo!DLW%ALDERAAN.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cfry%OZ.AI.MIT.EDU@navajo.stanford.edu,
navajo!Common-Lisp%SU-AI.ARPA@navajo.stanford.edu
In-Reply-To: Daniel L. Weinreb's message of Fri, 23 Jan 87 10:47 EST
Subject: fsymeval before arg-eval?
For compiled code, the macro/functional decision has been made at compile
time, and the question of order-of-evaluation is a legitimate question.
In fact, most implementations I'm aware of do the "fsymeval" *after* the
agruments computations in compiled code, but do it *before* them in the
interpreted code.
In an implementation where the "macro-p" question is decidable without
looking in the function cell (like, MacLisp and Interlisp), then the
interpreter wouldn't need to do the fsymeval before doing the argument
evaluations.
The other issue is decidibility of "special-form-p"; in a language where
the "special forms" are immutable (expect for macro-expanders for semantics
clarity), there is no need to look into the funtion cell to determine
whether or not the form is a "special form". Lisp/370 was implemented
this way also (or was intended to have this semantics!); it is generally
true for Common Lisp too.
But the real issue is that evaluating the functional position last is
very counterintuitive. It certainly wouldn't survive the Lisp1/Lisp2
challenge (which is a proposal to unify the function and value cells).
As far as I know, only VAX/NIL did the fsymeval in compiled code before
the argument computations. Do you know of any others.
-- JonL --
P.S. Historical perspective: Another variant of this problem is discussed
in a footnote to the paper "Lisp: Data Is Program -- A Tutorial in
Lisp" found in the Proceedings of the 1977 MACSYMA Users' Conference
(NASA CP 2012). See page 197. This footnote is particularly concerned
with multiple "evaluations" of the function context -- such as has
recently been proposed for Common Lisp as a way to accommodate the
Lisp1/Lisp2 controversy -- and in particular the side-effects which
may occur in the "evaluations".
∂23-Jan-87 1604 REM@IMSSS symeval before or after args-eval?
Received: from IMSSS by SAIL with PUP; 23-Jan-87 16:00 PST
Date: 23 Jan 1987 1557-PST
From: Rem@IMSSS
Subject: symeval before or after args-eval?
To: COMMON-LISP@SU-AI
It seems there are several possible decisions, each of which involves some
change to CLtL:
(1) Require symeval before args-eval in both interpretor and compiled-code.
This may require overhaul of several implementations.
(2) Leave it up to the implementor, but say "it is an error" to write any
code that side-effects the functional binding of the CAR of a form when
evaluating the args (map-eval the CDR) since its behaviour would be different
on various implementations and might be different between interpreted and
compiled within a single implementation.
<<symeval should read fneval or whatever above>>
(3) Require lookup of type of function before evaluating args, but require
actual fetching of function definition after evaluating args, and way
"it is an error" to redefine a function to a macro or vice versa during
evaluating args.
I vote for (2) as being less drastic than either of the others.
-------
∂24-Jan-87 1231 LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu Pattern matching in CL
Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Jan 87 12:27:46 PST
Received: by lindy.STANFORD.EDU; Sat, 24 Jan 87 12:25:55 PST
Date: Sat, 24 Jan 87 12:23:58 PST
From: <LINNDR@vuengvax.bitnet>
Reply-To: LINNDR%VUENGVAX.BITNET@forsythe.stanford.edu
To: common-lisp@sail.stanford.edu
Subject: Pattern matching in CL
Date: Sat, 24 Jan 87 10:32 CST
From: <LINNDR@VUENGVAX.BITNET> (David Linn)
Subject: Pattern matching in CL
To: common-lisp@sail.stanford.edu
X-Original-To: common-lisp@sail.stanford.edu, LINNDR
For the last couple of years, we have been using PEARL in
our (Franz)LISP applications. Now that we have CL, we are looking for
a PEARL port or a comparable pattern-matching/database-handling package
in CL. Can you help? Please reply by mail and I'll summarize to the list
if there is sufficient interest.
David Linn (The Shell Answer Man)
LINNDR%VUENGVAX.BITNET@WISCVM.WISC.EDU | Internet
...!psuvax1!vuengvax.bitnet!linndr | UUCP
∂24-Jan-87 1722 Mailer@XX.LCS.MIT.EDU another question about defmacro lambda lists
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Jan 87 17:22:47 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 24 Jan 87 20:22-EST
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 26179; 24 Jan 87 20:23:52-EST
Received: from DWORKIN.PALLADIAN.COM by JASPER.PALLADIAN.COM via CHAOS with SMTP id 25654; 24 Jan 87 19:13:10-EST
Date: Sat, 24 Jan 87 19:12 EST
From: Glenn S. Burke <gsb@JASPER.PALLADIAN.COM>
Subject: another question about defmacro lambda lists
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%utah-orion@UTAH-CS.ARPA
cc: common-lisp@sail.stanford.edu, gsb@JASPER.PALLADIAN.COM
In-Reply-To: <870123150538.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870124191250.1.GSB@DWORKIN.PALLADIAN.COM>
Reply-To: Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Fri, 23 Jan 87 15:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 23 Jan 87 12:27:25 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Does it make sense for nested lambda lists in a defmacro to contain things
like &environment? CLtL does not say whether the non-top-level lambda lists
should be ordinary function lambda lists or whether they can use the extended
syntax.
They certainly need to allow destructuring; it wouldn't make sense to have only
a single level of destructuring. I don't think &whole and &environment make
sense any place other than at the top level, though.
&whole makes sense for subforms; you need it if you want a pointer to the subform
being destructured. I am assuming it applies to the subform being destructured
against the lambda-list the &whole occurs in, not that it applies to the outermost
form.
∂24-Jan-87 2344 Hvatum.DLAB@MIT-MULTICS.ARPA quoted structure
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jan 87 23:44:06 PST
Date: Sun, 25 Jan 87 02:41 EST
From: Hvatum@MIT-MULTICS.ARPA
Subject: quoted structure
To: common-lisp@SAIL.STANFORD.EDU
cc: Hvatum@MIT-MULTICS.ARPA
Message-ID: <870125074145.262992@MIT-MULTICS.ARPA>
From: Steve Bacher (C.S.Draper Lab)
Subject: Re: is quoted structure "constant"?
In-reply-to: REM%IMSSS@SU-AI.ARPA
> Where quoted structure
> appears as second argument to MEMQ or MEMBER or as either argument to
> EQ or EQUAL et al, it is obviously not changeable hence constant.
This is not necessarily true in the case of MEMQ/MEMBER. Since MEMBER
(let's elide mention of MEMQ as it is not true CL) returns a sublist
of its second arg by definition, it cannot be guaranteed that the
second arg is unchanged. The compiler can assume constancy of the
second arg to MEMBER only when the function is being used as a
predicate (or for side-effect only, which is meaningless for MEMBER).
- SEB
≠
∂25-Jan-87 1742 Moon@RIVERSIDE.SCRC.Symbolics.COM another question about defmacro lambda lists
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jan 87 17:42:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 95904; Sun 25-Jan-87 20:04:21 EST
Date: Sun, 25 Jan 87 20:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: another question about defmacro lambda lists
To: Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
cc: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@sail.stanford.edu
In-Reply-To: <870124191250.1.GSB@DWORKIN.PALLADIAN.COM>
Message-ID: <870125200425.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat, 24 Jan 87 19:12 EST
From: Glenn S. Burke <gsb@JASPER.PALLADIAN.COM>
Date: Fri, 23 Jan 87 15:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 23 Jan 87 12:27:25 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Does it make sense for nested lambda lists in a defmacro to contain things
like &environment? CLtL does not say whether the non-top-level lambda lists
should be ordinary function lambda lists or whether they can use the extended
syntax.
They certainly need to allow destructuring; it wouldn't make sense to have only
a single level of destructuring. I don't think &whole and &environment make
sense any place other than at the top level, though.
&whole makes sense for subforms; you need it if you want a pointer to the subform
being destructured. I am assuming it applies to the subform being destructured
against the lambda-list the &whole occurs in, not that it applies to the outermost
form.
Well, there's something funny here. Consider:
(defmacro foo (&rest x &whole y) ...)
(defmacro bar ((&rest x &whole y)) ...)
In bar, x and y are bound to the same value, but in foo x is bound to
(cdr y). I suppose it makes sense to allow &whole in bar anyway, but it
could be confusing to some users.
∂25-Jan-87 1743 Moon@RIVERSIDE.SCRC.Symbolics.COM fsymeval before arg-eval?
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jan 87 17:43:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 95912; Sun 25-Jan-87 20:28:09 EST
Date: Sun, 25 Jan 87 20:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: fsymeval before arg-eval?
To: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>
cc: dlw@STONY-BROOK.SCRC.Symbolics.COM, cfry%OZ.AI.MIT.EDU@MIT-MC.ARPA,
Common-Lisp@sail.stanford.edu
In-Reply-To: <8701232149.AA10259@bhopal.edsel.com>
Message-ID: <870125202815.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 23 Jan 87 13:49:53 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
For compiled code, the macro/functional decision has been made at compile
time, and the question of order-of-evaluation is a legitimate question.
In fact, most implementations I'm aware of do the "fsymeval" *after* the
agruments computations in compiled code, but do it *before* them in the
interpreted code.
....
As far as I know, only VAX/NIL did the fsymeval in compiled code before
the argument computations. Do you know of any others.
Some Symbolics machines do it before, some do it after. I'm less
familiar with other implementations, but I expect we could find several
examples of each way of doing it.
It sounds like it's going to be difficult to come to a concensus on this
across a wide spectrum of implementations. Since dynamically changing
the global function definition of symbols is not something that Common
Lisp promotes as a standard programming technique, perhaps it's best
just to leave it undefined. Normally when the function being called
is not a constant, FUNCALL would be used.
∂26-Jan-87 0755 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Are functions defined by FLET surrounded by an implicit BLOCK?
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jan 87 07:55:10 PST
Date: Mon, 26 Jan 1987 10:47 EST
Message-ID: <STEVER.12274016783.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp@SAIL.STANFORD.EDU
Subject: Are functions defined by FLET surrounded by an implicit BLOCK?
CLtL specifically states that DEFUN bodies are implicitly wrapped in a
BLOCK with the same name as the function being defined. Is this true
of FLET and LABELs as well?
Stever
∂26-Jan-87 1407 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM another question about defmacro lambda lists
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Jan 87 14:06:20 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 49287; 26 Jan 87 11:21:23 EST
Date: Mon, 26 Jan 87 11:20 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: another question about defmacro lambda lists
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
cc: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@sail.stanford.edu
In-Reply-To: <870125200425.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870126112040.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Sun, 25 Jan 87 20:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Well, there's something funny here. Consider:
(defmacro foo (&rest x &whole y) ...)
(defmacro bar ((&rest x &whole y)) ...)
In bar, x and y are bound to the same value, but in foo x is bound to
(cdr y). I suppose it makes sense to allow &whole in bar anyway, but it
could be confusing to some users.
I agree it isn't symmetric, but there probably are cases that really are
useful. Something like
(defmacro with-open-file ((&whole stuff var filename &rest keys)
&body body)
...
(warn "The first form of with-open-file, ~S, is malformed." stuff)
...)
∂26-Jan-87 1413 Masinter.pa@Xerox.COM survey on Lisp courses
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 14:13:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 87 13:55:15 PST
Date: 26 Jan 87 14:00 PST
From: Masinter.pa@Xerox.COM
Subject: survey on Lisp courses
To: common-lisp@sail.stanford.edu
Message-ID: <870126-135515-4367@Xerox>
I sent out a request several weeks ago asking for information on Common
Lisp courses that people had taken or taught. I collected together the
responses (information about several different Lisp courses), edited out
what I thought might not be for public consumption, and have stored on
the file [parc-vax.xerox.com]/user/ftp/pub/lisp-course-survey.txt. The
file should be available for anonymous ARPA ftp.
I said I would send the results to those who contributed, but there were
enough responses of the form "I don't have anything to contribute but
I'd like to see the result anyway" that I thought I would broadcast the
result.
If you have anything to add, or don't have access and would like me to
mail you a copy, please let me know.
Thanks to all who responded.
My observation: most of the subtleties of programming Common Lisp in a
portable, efficient manner are not covered well. There may be some
industrial/training sessions, but they seem to be too short to address
most of the issues.
A number of people that I've spoken with (whose responses are not
reflected in the survey) agreed independently that the only text that
covered programming style reasonably well was Abelson and Sussman's
Structure and Interpretation of Computer Programs. There was more than
one recommendation that a practical course was to start with that (and
Scheme) and then transition to Common Lisp, explaining the compromises
of Common Lisp along the way.
∂26-Jan-87 1456 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM another question about defmacro lambda lists
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Jan 87 14:06:20 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 49287; 26 Jan 87 11:21:23 EST
Date: Mon, 26 Jan 87 11:20 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: another question about defmacro lambda lists
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
Glenn S. Burke <GSB%JASPER@LIVE-OAK.LCS.MIT.EDU>
cc: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@sail.stanford.edu
In-Reply-To: <870125200425.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870126112040.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Sun, 25 Jan 87 20:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Well, there's something funny here. Consider:
(defmacro foo (&rest x &whole y) ...)
(defmacro bar ((&rest x &whole y)) ...)
In bar, x and y are bound to the same value, but in foo x is bound to
(cdr y). I suppose it makes sense to allow &whole in bar anyway, but it
could be confusing to some users.
I agree it isn't symmetric, but there probably are cases that really are
useful. Something like
(defmacro with-open-file ((&whole stuff var filename &rest keys)
&body body)
...
(warn "The first form of with-open-file, ~S, is malformed." stuff)
...)
∂26-Jan-87 1456 Masinter.pa@Xerox.COM survey on Lisp courses
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 14:13:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 87 13:55:15 PST
Date: 26 Jan 87 14:00 PST
From: Masinter.pa@Xerox.COM
Subject: survey on Lisp courses
To: common-lisp@sail.stanford.edu
Message-ID: <870126-135515-4367@Xerox>
I sent out a request several weeks ago asking for information on Common
Lisp courses that people had taken or taught. I collected together the
responses (information about several different Lisp courses), edited out
what I thought might not be for public consumption, and have stored on
the file [parc-vax.xerox.com]/user/ftp/pub/lisp-course-survey.txt. The
file should be available for anonymous ARPA ftp.
I said I would send the results to those who contributed, but there were
enough responses of the form "I don't have anything to contribute but
I'd like to see the result anyway" that I thought I would broadcast the
result.
If you have anything to add, or don't have access and would like me to
mail you a copy, please let me know.
Thanks to all who responded.
My observation: most of the subtleties of programming Common Lisp in a
portable, efficient manner are not covered well. There may be some
industrial/training sessions, but they seem to be too short to address
most of the issues.
A number of people that I've spoken with (whose responses are not
reflected in the survey) agreed independently that the only text that
covered programming style reasonably well was Abelson and Sussman's
Structure and Interpretation of Computer Programs. There was more than
one recommendation that a practical course was to start with that (and
Scheme) and then transition to Common Lisp, explaining the compromises
of Common Lisp along the way.
∂26-Jan-87 1605 Masinter.pa@Xerox.COM [PARCVAX.XEROX.COM, not PARC-VAX] and Re: symbol-function of
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 15:58:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 87 14:36:34 PST
Date: 26 Jan 87 14:42 PST
From: Masinter.pa@Xerox.COM
Subject: [PARCVAX.XEROX.COM, not PARC-VAX] and Re: symbol-function of
non-functions
In-reply-to: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>'s message
of Fri, 23 Jan 87 09:21 EST
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870126-143634-4459@Xerox>
[For those attempting to FTP the lisp course survey, the host name is
PARCVAX.XEROX.COM, not PARC-VAX.XEROX.COM.]
There was a misconception in David Plummer's reply that I think should
be cleared up. The explaination given was one where the
"symbol-function" implicit in obtaining the functional interpretation of
car-of-form was repeated until the result was not a symbol. I.e., Dave
assumed that
(defun bottom () "The end!")
(setf (symbol-function 'test) 'bottom)
(test)
would return "The end!"
(This was the basis for the description that the reason why NIL fails as
a value for symbol-function is because NIL has no function definition.)
Nothing in CLtL requires this to be true. Many Common Lisp
implementations do not allow this form, although it is apparently
allowed in some.
Since apparently many people believe this is a property of Common Lisp,
it may be grounds for a "clarification".
∂26-Jan-87 1853 Masinter.pa@Xerox.COM face-to-face meeting at X3
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 18:53:46 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 26 JAN 87 18:33:12 PST
Date: 26 Jan 87 18:39 PST
From: Masinter.pa@Xerox.COM
Subject: face-to-face meeting at X3
To: cl-cleanup@sail.stanford.edu
Message-ID: <870126-183312-4815@Xerox>
Given the very slow rate of discussion, progress, or even responses on
even the simplest of issues, it seems fairly clear that a face-to-face
meeting to deal with some the issues is necessary.
It seems unlikely that we can have any proposals ready for formal voting
by X3j13 by the deadline.
If we can agree on the format that we would like issues to be expressed,
we might be able to broadcast it in time for us to consider them, say,
in a meeting after x3j13 on March 19?
∂26-Jan-87 1944 FAHLMAN@C.CS.CMU.EDU face-to-face meeting at X3
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Jan 87 19:43:59 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 26 Jan 87 22:43:57-EST
Date: Mon, 26 Jan 1987 22:43 EST
Message-ID: <FAHLMAN.12274147112.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: face-to-face meeting at X3
In-reply-to: Msg of 26 Jan 1987 21:39-EST from Masinter.pa at Xerox.COM
I agree that it now seems unlikely that we will have anything solid to
send out by the pre-meeting deadline. If people get moving on these
things, we might be able to have a bunch of well-debugged proposals
ready to circulate at the meeting, so that people can see that SOME
progress is being made. These can be voted on later, by mail or at the
following meeting.
Since only three of us seem to be participating in the mail discussions,
I suppose a face-to-face meeting of the cleanup committee would be
useful if more than a few of us will be there. If it's only the same
three people who are communicating by mail, then nothing is gained by a
meeting.
My own preference would be to meet just before the full X3J13 comittee
meets, rather than after. There are two reasons for this: First, if we
caucus before the full meeting, it maximizes the chance that we'll have
some results to present at the larger meeting (or that we'll understand
why the committee is making no progress and have some ideas about how to
fix that).
Second, my own plan was to fly west on the Saturday before the meeting
in order to get a halfway reasonable plane fare by staying over one
Saturday night -- I have to check, but I don't think the discount on
Delta does me any good at all, since Delta doesn't fly into Pittsburgh.
The plan was to redeye back right after the meeting; the trip already
has me away from home for five nights, and I'm very reluctant to extend
it for another night. So my preference would be to meet Monday morning,
unless that screws up the travel plans for everyone else. If we do our
homework, a short meeting should accomplish everything that is going to
be accomplished.
-- Scott
∂26-Jan-87 2040 hpfclp!diamant@hplabs.HP.COM Re: preprocessor-based Common Lisps
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 26 Jan 87 20:39:58 PST
Received: by hplabs.HP.COM ; Mon, 26 Jan 87 20:39:37 pst
Received: from hpfcjrd.HP.COM by hpfclp; Mon, 26 Jan 87 20:41:39 mst
Received: by hpfcjrd; Mon, 26 Jan 87 20:40:33 mst
Date: Mon, 26 Jan 87 20:40:33 mst
From: John Diamant <hpfclp!diamant@hplabs.HP.COM>
Return-Path: <diamant@hpfcjrd>
Message-Id: <8701270340.AA18791@hpfcjrd.HP.COM>
To: common-lisp@sail.stanford.edu
Subject: Re: preprocessor-based Common Lisps
Since I brought up the subject of preprocessors in Common Lisp implementations,
I have been asked to describe the HP preprocessor. Here is a small paragraph
written by one of the implementors of the preprocessor (Jerry Duggan):
> HP chose to implement its Common Lisp system based on a preprocessor
> model. The preprocessor takes "raw" Common Lisp code, expands macros,
> and translates this lisp code into an internal form which is used as
> input to both the interpreter and compiler. Additionally, the
> preprocessor may perform optimizations on the Lisp code. There were
> three reasons why the implementation was done this way. First, it was
> a means to ensure consistent semantics between the interpreted and
> compiled code, since both the interpreter and compiler use the same
> input. Second, the preprocessor performs all the analysis required
> for lexical scoping, so the implementation of lexical scoping was easy
> and efficient in the interpreter, and closures could be compiled
> efficiently. Third, all Common Lisp forms are translated into a basic
> internal form which has about thirty different constructs. The small
> number of constructs limits the allowed input to the interpreter and
> compiler, making them both more manageable.
The optimizations that Jerry refers to are primarily source-level
translations, as opposed to machine language optimizations. Since the
preprocessor is limited to source and interal representations, it cannot
perform optimizations directly on machine code since that hasn't been
generated yet.
Preprocessed code can be traslated back into equivalent source code, but that
source code may not be the same as the original source, because of the
source-level optimizations (including macro-expansion) done on it. We added
a declaration corresponding to the speed declaration for the interpreter
(technically the preprocessor when called from the interpreter), so that a
different degree of optimization can be enabled for interpreted and compiled
code.
John Diamant diamant%hpfclp@hplabs.hp.com
∂27-Jan-87 0407 @DIAMOND.S4CC.Symbolics.COM,@KOYAANISQATSI.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM [PARCVAX.XEROX.COM, not PARC-VAX] and Re: symbol-function of
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 27 Jan 87 04:04:40 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 49828; 27 Jan 87 10:01:38 EST
Date: Tue, 27 Jan 87 10:00 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: [PARCVAX.XEROX.COM, not PARC-VAX] and Re: symbol-function of
non-functions
To: Masinter.pa@Xerox.COM, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <870126-143634-4459@Xerox>
Message-ID: <870127100054.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 26 Jan 87 14:42 PST
From: Masinter.pa@Xerox.COM
There was a misconception in David Plummer's reply that I think should
be cleared up.
...
Nothing in CLtL requires this to be true.
Inversely, I believe nothing in CLtL requires this to be false. In
private communications with Masinter I "proved" based on 5 assumptions
which we can redistribute if necessary.
Many Common Lisp
implementations do not allow this form, although it is apparently
allowed in some.
Since apparently many people believe this is a property of Common Lisp,
it may be grounds for a "clarification".
∂27-Jan-87 1119 Moon@RIVERSIDE.SCRC.Symbolics.COM Are functions defined by FLET surrounded by an implicit BLOCK?
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jan 87 11:16:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 96483; Tue 27-Jan-87 14:13:52 EST
Date: Tue, 27 Jan 87 14:14 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Are functions defined by FLET surrounded by an implicit BLOCK?
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <STEVER.12274016783.BABYL@MIT-OZ>
Message-ID: <870127141401.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 26 Jan 1987 10:47 EST
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
CLtL specifically states that DEFUN bodies are implicitly wrapped in a
BLOCK with the same name as the function being defined. Is this true
of FLET and LABELs as well?
I believe it should be, but CLtL doesn't say. This seems like it comes under
our subcommittee's purview. Maybe this is an easy issue to settle?
(Of course MACROLET should be added to the list.)
∂27-Jan-87 1432 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Jan 87 14:30:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 27 JAN 87 13:41:14 PST
Date: 27 Jan 87 13:48 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by
FLET surrounded by an implicit BLOCK?
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 27 Jan 87 14:14 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870127-134114-5706@Xerox>
Does this summarize the issue? I don't want to have to do this for every
proposal myself, and would like people who want to propose things to do
some of the homework necessary.
Issue: FLET-IMPLICIT-BLOCK
Reference: >>???<<
Description: Do flet, labels, and macrolet have an implicit block around
their bodies like the body of a DEFUN?
CLtL is unclear.
Category: Ommission.
Proposal: FLET-IMPLICIT-BLOCK:YES
Yes, FLET, LABELS, and MACROLET have an implicit block around the body
with the same name.
---
Rationale:
a) This does not generally reflect current practice, for example,
VaxLisp 2.0 and Xerox Common Lisp (currently) do not add the implicit
block, while Symbolics and Kyoto Common Lisp do add the implicit block.
(See test case below.) I don't know what Lucid does.
b) the cost of adopting this change is small, since adding the implicit
block is a simple extension for any common lisp implementation.
c) the cost of not adopting the change is continued inconsistancy
between DEFUN-formed functions and FLET defined functions, and
consistency is valued.
d) the cost of converting existing code is relatively small, in that it
is unlikely that any code in a current implementation that doesn't have
an implicit block around FLET code might also do a RETURN-FROM a block
with the same name, e.g.,
Test case: (In cases where there is a simple example which illustrates
the ambiguity simply, it helps to give it. It makes deciding what
"current practice" is easily, for example.)
(DEFUN TEST () (FLET ((TEST (X) (IF X (RETURN-FROM TEST 4) 3)))
(LIST (TEST NIL) (TEST T))))
(TEST)
will return either (3 4) if this proposal is adopted, and might return 4
if an implementation did *not* add an implicit block.
∂27-Jan-87 2122 Moon@STONY-BROOK.SCRC.Symbolics.COM face-to-face meeting at X3
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jan 87 21:22:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 54423; Wed 28-Jan-87 00:21:01 EST
Date: Wed, 28 Jan 87 00:20 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: face-to-face meeting at X3
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12274147112.BABYL@C.CS.CMU.EDU>
Message-ID: <870128002049.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I intend to go to the March X3J13 meeting, but it's likely that I would
have substantial difficulty scheduling a face to face cl-cleanup
meeting. Anyway, what makes you think people who don't do their
homework when responding to electronic mail at their own pace in the
comfort of their own office would be any more likely to do homework in
preparation for a face to face meeting?
∂28-Jan-87 0646 MATHIS@ADA20.ISI.EDU Re: face-to-face meeting at X3
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 06:46:10 PST
Date: 28 Jan 1987 06:44-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: face-to-face meeting at X3
From: MATHIS@ADA20.ISI.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]28-Jan-87 06:44:20.MATHIS>
In-Reply-To: <870126-183312-4815@Xerox>
I think Scott made a good point about trying to have some items
for presentation at the meeting. I think it will take a meeting
or two to shake out the consideration and voting procedure. If
this committee had a small number of items (one or two hours of
discussion) to present, we could introduce them for discussion
but not a final vote (since they would not have been sent out
early enough). We could handle the discussion as if they had
been sent out on time, but at the end decide only to either go
with a mail ballot or hold the issue over for the next meeting.
My feeling is that the first meeting will primarily be to set the
style for presentation, consideration, and decision making.
A face-to-face meeting might have two purposes -- short strategy
for Palo Alto meeting presentation (this would take less than an
hour if you have some basics worked out before hand on the net)
and actually working out some technical issues (this could be
very long and holding it because people are not keeping up on the
net is the wrong reason, Moon's point is well taken).
My travel plans are similar to Scott's, but I'm not an important
participant in this meeting.
-- Bob
∂28-Jan-87 0713 FAHLMAN@C.CS.CMU.EDU Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 07:12:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 28 Jan 87 10:13:10-EST
Date: Wed, 28 Jan 1987 10:13 EST
Message-ID: <FAHLMAN.12274534737.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by
In-reply-to: Msg of 27 Jan 1987 16:48-EST from Masinter.pa at Xerox.COM
This issue was already in the ISSUES file. The following text is taken
from there:
---------------------------------------------------------------------------
Page ???:
In addition to DEFUN, the following macros implicitly wrap a BLOCK
around their bodies: DEFMACRO, DEFSETF, DEFINE-SETF-METHOD, and DEFTYPE.
Also, LABELS, FLET amd MACROLET should wrap a block around the bodies of
the locally defined functions. Users are encouraged to create such
blocks in their own macros where a body and an obvious block-name are
present.
---------------------------------------------------------------------------
Several points and issues:
1. Presumably we want to address DEFMACRO, DEFSETF, DEFINE-SETF-METHOD,
and DEFTYPE at the same time as FLET, LABELS, and MACROLET? Do these
forms raise any issues that are not raised by the others? I don't see
any. Rob tells me that Spice Lisp already installs blocks on all of
these forms additional forms, though we apparently do not do this on
FLET, LABELS, and MACROLET.
2. Do we want to suggest in any new manual that users provide such
blocks for their own macros if they take an arbitrary body? (Presumably
the right way to handle this is for our committee to pass along a set of
non-binding suggestions to the drafting committee. This would be one of
them; the business about avoiding confusing uses of the word "intern"
would be another. That way these suggestions don't get lost, but we
don't have to worry about formal votes tying the drafting committee's
hands in the choice of language.)
3. In the ISSUES file, I say that I think I am opposed to this proposal
on efficiency grounds. I no longer believe this to be a serious
problem. In compiled code, there is no issue: blocks that are not
actually used can be eliminated. I was thinking that this would require
the interpreter to code-walk in and modify FLET, LABELS, and MACROLET
forms at defun time, but clearly this is not the right implementation
strategy. Instead one would modify FLET and friends to establish the
block upon entry. This slows down these forms in the interpreter a bit,
whether the block is used or not, but this slowdown in relatively rare
forms, interpreter only, should not hurt much.
4. Is there an issue here with tail-recursion? Could the presence of
these implicit blocks make it much harder to do tail-recursion
optimization? I don't see the problem now, but I have a note that
someone raised this issue in earlier discussions.
-- Scott
∂28-Jan-87 0803 FAHLMAN@C.CS.CMU.EDU [RAM: Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 08:03:30 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 28 Jan 87 11:04:01-EST
Date: Wed, 28 Jan 1987 11:03 EST
Message-ID: <FAHLMAN.12274543996.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [RAM: Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by]
Date: Wednesday, 28 January 1987 10:58-EST
From: Rob MacLachlan <RAM>
To: Scott E. Fahlman <Fahlman>
Re: Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by
In case nobody else answers, the issue with tail-recursion was
that Block in the interpreter cannot mindlessly push things on the
stack if tail recursion is to be preserved. Implementations that
always created catch frames for Block were finding that tail recursion
was being inhibited in Defun due to the implicit block. The fix is to
cons the necessary structure on the heap. Repeated consing can be
avoided by explicitly passing this "continuation" into tail-recursive
invocations of eval.
This issue is almost totally irrelevant in the current discussion,
since the implicit Defun block already causes these problems and
isn't going to go away.
Rob
∂28-Jan-87 1044 Dan@think.com survey on Lisp courses
Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 28 Jan 87 10:43:39 PST
Received: from Godot.Think.COM by zarathustra.think.com; Wed, 28 Jan 87 13:42:52 EST
Received: from epicurus by Godot.Think.COM via CHAOS; Wed, 28 Jan 87 13:42:48 EST
Date: Wed, 28 Jan 87 13:44 EST
From: Dan Aronson <Dan@think.com>
Subject: survey on Lisp courses
To: Masinter.pa@xerox.com
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <870126-135515-4367@Xerox>
Message-Id: <870128134411.8.DAN@EPICURUS.THINK.COM>
Hi,
FTP tells me: /user/ftp/pub/lisp-course-survey.txt: No such file or directory.
If that is where it really is then our ftp is broken and could you send me a copy.
If it is somewhere else could you tell me where.
--Dan Aronson
Thinking Machines Corporation
dan@think.com
∂28-Jan-87 1051 RPG the basic policy was decided in japan
∂28-Jan-87 0720 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET the basic policy was decided in japan
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Jan 87 07:20:45 PST
Received: from utokyo-relay by csnet-relay.csnet id ai00912; 28 Jan 87 10:05 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA08814; Wed, 28 Jan 87 22:11:20+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA04040; Wed, 28 Jan 87 21:58:08+0900
Date: Wed, 28 Jan 87 21:58:08+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8701281258.AA04040@ccut.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: the basic policy was decided in japan
Dear Sirs,
We had meetings and decided the basic policy.
It is based on the agreement of Jeida Common Lisp committee, JIS Lisp WG,
MITI japan.
That is,
Taking account of the trinity structure of the earth, we will consider
ISO related things as a middle or long range issue.
JIS Lisp WG will correspond to this issue.
JIS Lisp WG will also propose a design of a Japanese draft.
Jeida Common Lisp committee will correpond to ANSI activities.
(if X3J13 agree)
Jeida Common Lisp Committee will make a Jeida standard,
which is not authorised by japanese government, but is agreed to conform
among the members including USA companies.
Jeida standard will try to synchronize with ANSI standard and
hopefully converge in early 1988.
JIS Lisp WG will watch this industrial process, and will decide whether
WG will stop to design a draft which does not always be a Common Lisp but
which we may need in the future along with the progress of the technology.
The above story I wrote is a very hot one !
So, all the contexts are not always stable in a week or two.
But I think X3J13 scheduling for the next meeting have not so much time now.
So, I posted here.
I am compiling a report on a japanese standardization efforts with the assist
of Jeida members. It will finish at Feb. 6th, not on 4th.
I hope the documents of us will be avilable to you all as soon as possible.
Thank you.
Masayuki Ida
∂28-Jan-87 1152 israel@brillig.umd.edu survey on Lisp courses
Received: from BRILLIG.UMD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 11:51:44 PST
Received: by brillig.umd.edu (5.9/4.7)
id AA01721; Wed, 28 Jan 87 14:48:18 EST
Date: Wed, 28 Jan 87 14:48:18 EST
From: Bruce Israel <israel@brillig.umd.edu>
Message-Id: <8701281948.AA01721@brillig.umd.edu>
To: Dan@zarathustra.think.com
Cc: Masinter.pa@xerox.com, common-lisp@sail.stanford.edu
Subject: survey on Lisp courses
From: Dan Aronson <Dan@zarathustra.think.com>
FTP tells me: /user/ftp/pub/lisp-course-survey.txt: No such file
I got bit by this one also. It seems that ftp doesn't like absolute
pathnames. Since you come in in the directory /usr/ftp, just do
a 'cd pub' followed by a 'get lisp-course-survey.txt localfile' and
all will work fine.
Bruce
∂28-Jan-87 1659 TOURETZKY@C.CS.CMU.EDU extending sequence functions to arrays
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Jan 87 16:59:02 PST
Received: ID <TOURETZKY@C.CS.CMU.EDU>; Wed 28 Jan 87 19:59:30-EST
Date: Wed 28 Jan 87 19:59:30-EST
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: extending sequence functions to arrays
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <12274641487.9.TOURETZKY@C.CS.CMU.EDU>
I propose to make sequence functions more useful by extending them (very
slightly) to treat arrays of rank > 1 as if they were one dimensional vectors
:DISPLACED-TO the array. Presently, programmers are forced to build displaced
vectors by hand in order to do simple operations on matrices. Consider the
following examples:
(setq a (make-array (list 5 7))) ;the matrix A
(setq b (make-array (list 5 7))) ;the matrix B
(setq av (make-array 35 :displaced-to a)) ;hack for accessing A
(setq bv (make-array 35 :displaced-to b)) ;hack for accessing B
Current Code New Code Equivalent Hack
1. zero all array elements
(dotimes (i 5) (fill a 0) == (fill av 0)
(dotimes (j 7)
(setf (aref a i j) 0)))
2. copy array A into array B
...the obvious nested dotimes... (replace b a) == (replace bv av)
3. check if A contains a 0 anywhere
(block foo (find 0 a) == (find 0 av)
(dotimes (i 5)
(dotimes (j 7)
(if (= (aref a i j) 0)
(return-from foo t)))))
4. find the minimum element of A
(let ((m (aref a 0 0))) (reduce #'min a) == (reduce #'min av)
(dotimes (i 5)
(dotimes (j 7)
(setq m (min m (aref a i j)))))
m)
This proposal doesn't impose any significant work on implementors since
displaced arrays are already part of the language. It also does not introduce
any conceptual ambiguities, e.g., in the handling of :START and :END keywords,
values returned by, LENGTH, ELT, and REVERSE, etc., since the behavior of
sequence functions on vectors is already well-defined.
-- Dave Touretzky, CMU Computer Science Dept.
-------
∂28-Jan-87 1755 Masinter.pa@Xerox.COM Re: face-to-face meeting at X3
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jan 87 17:49:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 JAN 87 16:40:50 PST
Date: 28 Jan 87 16:40 PST
From: Masinter.pa@Xerox.COM
Subject: Re: face-to-face meeting at X3
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 28 Jan 87 00:20 EST
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870128-164050-1201@Xerox>
The purpose of a face-to-face meeting:
If we met on Sunday afternoon and Monday morning, spending, say, 10
minutes for each issue in the issues file, with the focus of deciding
whether we were in substantial agreement or whether it was a "hard"
problem, we might be able to separate out the hard issues from the easy
ones, and have something that we could "ballot".
It is easier to get people to pay attention if they're sitting in a
meeting than if they are reading their mail with 50 other things to do,
and to reach consensus. Over the mail, one can't assume silence means
assent -- maybe people are reading their mail only once a week.
I think the meeting would be useful even if only a few of the committee
showed up; the purpose is not to "decide", but to put together a
position held by more than one member, although the more who can make
it, the better (up to a limit).
∂28-Jan-87 1754 Gregor.pa@Xerox.COM Re: survey on Lisp courses
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Jan 87 17:48:16 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 28 JAN 87 13:06:38 PST
Date: 28 Jan 87 13:06 PST
From: Gregor.pa@Xerox.COM
Subject: Re: survey on Lisp courses
In-reply-to: Dan Aronson <Dan@think.com>'s message of Wed, 28 Jan 87
13:44 EST
To: Dan@think.com
cc: Masinter.pa@Xerox.COM, common-lisp@sail.stanford.edu
Message-ID: <870128-130638-114@Xerox>
Try, /pub/lisp-course-survey.txt.
∂29-Jan-87 1247 @DIAMOND.S4CC.Symbolics.COM:chaowatkins@STONY-BROOK.SCRC.Symbolics.COM please add me to common-lisp mailing list
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 29 Jan 87 12:44:18 PST
Received: from PENG.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 50948; Thu 29-Jan-87 15:41:00 EST
Date: Thu, 29 Jan 87 15:40 EST
From: susan watkins <chaowatkins@STONY-BROOK.SCRC.Symbolics.COM>
Subject: please add me to common-lisp mailing list
To: common-lisp@sail.stanford.edu
Message-ID: <870129154045.4.CHAOWATKINS@PENG.S4CC.Symbolics.COM>
my arpa net address is:
frawley@scrc-stony-brook.arpa
thanks.
∂29-Jan-87 1247 Mailer@XX.LCS.MIT.EDU Mentioning name twice in multiple-value-setq
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jan 87 12:44:07 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jan 87 15:41-EST
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 26744; 29 Jan 87 15:43:58-EST
Received: from KITTYHAWK.PALLADIAN.COM by JASPER.PALLADIAN.COM via INTERNET with SMTP id 26129; 29 Jan 87 01:12:23-EST
Date: Thu, 29 Jan 87 01:11 EST
From: K. Shane Hartman <SHANE@JASPER.PALLADIAN.COM>
Subject: Mentioning name twice in multiple-value-setq
To: common-lisp@sail.stanford.edu
Message-ID: <870129011156.4.SHANE@KITTYHAWK.PALLADIAN.COM>
Reply-To: K. Shane Hartman <SHANE%JASPER@LIVE-OAK.LCS.MIT.EDU>
(multiple-value-setq (x x) (values 1 2))
Is the value of x defined after executing the previous form?
If so, what is the value? The same question could be asked of
multiple-value-bind.
-[Shane]->
∂29-Jan-87 1946 Pavel.pa@Xerox.COM MAKUNBOUND vs. special binding
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Jan 87 19:41:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 29 JAN 87 19:41:50 PST
Date: 29 Jan 87 19:41 PST
From: Pavel.pa@Xerox.COM
Subject: MAKUNBOUND vs. special binding
To: Common-Lisp@SAIL.Stanford.EDU
Message-ID: <870129-194150-1540@Xerox>
The description of the function MAKUNBOUND is as follows:
MAKUNBOUND causes the dynamic (special) variable named by
"symbol" to become unbound (have no value).
I'm not sure I understand what this means in certain circumstances.
Consider the following program:
(defvar *foo* 17)
(defun foo ()
(test-it) ; First
(let ((*foo* 18))
(bar)
(test-it)) ; Fourth
(test-it)) ; Fifth
(defun bar ()
(test-it) ; Second
(let ((*foo* 19))
(baz)
(test-it))) ; Third
(defun baz ()
(makunbound '*foo*))
(defun test-it ()
(format t "~S " (not (null (boundp '*foo*)))))
(foo)
What should this print? At the time the makunbound is performed, there
are three bindings of *foo*.
1) Are all of them destroyed? That is, should this print out T T NIL
NIL NIL?
2) Or is only the innermost binding undone (T T NIL T T)?
3) Alternatively, perhaps it should simply make the innermost binding
invisible, so that this would print T T T T T...
Should the function have different effects in deep-bound implementations
from shallow-bound ones?
I would greatly prefer that it were "an error" to MAKUNBOUND any symbol
that had a binding other than the one at top level. Otherwise, you can
get into this nonsensical situation where a variable is unbound in one
function but somehow becomes bound again when you return from that
function, as is the case in the second of my proposed answers.
It should be noted that Lucid, VaxLisp, and CLisp all print T T NIL T T.
Ugh.
Pavel
∂29-Jan-87 2013 Moon@STONY-BROOK.SCRC.Symbolics.COM MAKUNBOUND vs. special binding
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jan 87 20:11:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 58020; Thu 29-Jan-87 23:09:48 EST
Date: Thu, 29 Jan 87 23:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MAKUNBOUND vs. special binding
To: Pavel.pa@Xerox.COM
cc: Common-Lisp@SAIL.Stanford.EDU
In-Reply-To: <870129-194150-1540@Xerox>
Message-ID: <870129230927.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I believe the problem here is just the unfortunate use of the word
"bind" to mean two different things. (1) A variable is bound to
a value when evaluating that variable produces that value, and is
unbound when evaluating that variable is an error. (2) A special
variable is bound when its value has been saved upon entry to a
dynamic extent, and will be restored upon exit. This poor use of
English seems to date back to the earliest days of Lisp, as far as
I can tell, but maybe it's time to deep-six it.
MAKUNBOUND refers to definition 1. Thus the answer to your question is
the innermost binding (definition 1) is undone, while the innermost
binding (definition 2) remains unaffected.
∂30-Jan-87 0712 FAHLMAN@C.CS.CMU.EDU Documents
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jan 87 07:12:21 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 30 Jan 87 10:12:55-EST
Date: Fri, 30 Jan 1987 10:12 EST
Message-ID: <FAHLMAN.12275058967.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Documents
Do we want to clean up the "issues" document (removing some of my
editorial comments) and put that out as an X3J13 working document before
the February deadline? Just compiling that document is progress of a
sort, and it will give people a clear idea of what's on the table. It
would serve as an update of Steele's old proposals document, which I
believe is already and official X3J13 document.
-- Scott
∂30-Jan-87 0716 Hvatum.DLAB@MIT-MULTICS.ARPA &whole cum destructuring
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jan 87 07:16:27 PST
Date: Fri, 30 Jan 87 08:55 EST
From: Hvatum@MIT-MULTICS.ARPA
Subject: &whole cum destructuring
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870130135555.226863@MIT-MULTICS.ARPA>
From: Steve Bacher (C.S.Draper Lab)
In-reply-to: David C. Plummer <DCP at SCRC-QUABBIN>
> (defmacro with-open-file ((&whole stuff var filename &rest keys)
> &body body)
> ...
> (warn "The first form of with-open-file, ~S, is malformed." stuff)
> ...)
How useful is this really? It depends on how destructuring is
implemented. The following cases are possible, given passing a badly
formed argument (e.g. a symbol FOO) as arg 1 to with-open-file:
(1) The prologue code that destructures the argument attempts to
destructure FOO and blows up (or causes an error trap).
(2) The prologue code that destructures the argument detects the
invalid actual parameter and signals an error, something like
"Error: Unable to destructure FOO into (var filename &rest keys)
in macro WITH-OPEN-FILE"
(3) The prologue code that destructures the argument detects the
invalid actual parameter and assigns some default value to
var, filename, and keys.
In (1) and (2), the macro expansion function will never get control
in order to tell the user anything about the value of the &whole
argument. In (3), it might not be possible to tell that there is
a problem (except by inspecting the &whole arg, in which case you
can just follow it up with a destructuring LET).
I know what you'll say: "That's just an example, there are other
applications", etc. True, but it seems to me that in most cases
you'll never make it that far in your code unless the value passed was
successfully destructured, and in that case you can easily
"de-destructure" it if you want.
I think that the meaning of &whole at other than "top-level" in a
DEFMACRO lambda list is questionable. I prefer to see nested
destructuring lambda lists as equivalent to "normal" lambda lists
(i.e. without the special DEFMACRO hair). Presumably the lambda list
that DEFMACRO sees at top level gets hacked up into a "true"
lambda list internally, and only the DEFMACRO expander itself knows
about &whole and &env. At least that's one possible
implementation/interpretation.
- SEB
≠
∂30-Jan-87 0836 shebs%utah-orion@utah-cs.arpa Destructuring and &whole
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jan 87 08:35:59 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA25397; Fri, 30 Jan 87 09:37:36 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA10271; Fri, 30 Jan 87 09:37:33 MST
Date: Fri, 30 Jan 87 09:37:33 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8701301637.AA10271@utah-orion.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Destructuring and &whole
The point has been made that &whole might be used for detecting failed
attempts at destructuring, but has been countered by the observation that
the CL standard doesn't say anything about what happens if destructuring
doesn't work. This greatly limits the usefulness of destructuring - persons
writing robust code must do all the dissection by hand. (This situation
also comes up in functional languages, whose proponents frequently boast of
the destructuring capability inherent in function calls, but who shrug if a
program fails utterly because of an argument mismatch.)
I see several choices, listed in order of difficulty:
1. Flip a coin to decide whether &whole can appear in several places or not,
change nothing else.
2. Specify some sort of behavior for anomalous situations during dissection,
perhaps no more than a condition to be handled by the error system.
3. Augment destructuring syntax to allow for several possibilities to be
tried in order. For instance, the two forms of defsetf could be decided
upon, based only on multiple patterns in the parameter list!
I favor the last, but it's probably not politically feasible :-). Perhaps
for EuLisp...
stan
∂30-Jan-87 0922 JAR@AI.AI.MIT.EDU MAKUNBOUND vs. special binding
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jan 87 09:21:07 PST
Date: Fri, 30 Jan 87 12:21:21 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: MAKUNBOUND vs. special binding
To: Moon@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SAIL.STANFORD.EDU, Pavel.pa@XEROX.COM
In-reply-to: Msg of Thu 29 Jan 87 23:09 EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Message-ID: <146816.870130.JAR@AI.AI.MIT.EDU>
Date: Thu, 29 Jan 87 23:09 EST
From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I believe the problem here is just the unfortunate use of the word
"bind" to mean two different things. (1) A variable is bound to
a value when evaluating that variable produces that value, and is
unbound when evaluating that variable is an error. (2) A special
variable is bound when its value has been saved upon entry to a
dynamic extent, and will be restored upon exit. This poor use of
English seems to date back to the earliest days of Lisp, as far as
I can tell, but maybe it's time to deep-six it.
Just for the record, MIT Scheme solves this terminology problem by using
the terms "bound" and "unassigned". "Unbound" refers more or less to
(2) and "unassigned" to (1). This works out pretty well. The
equivalent of MAKUNBOUND is a primitive which makes a variable become
unassigned, and it has a semantics similar to SETQ. There isn't any
primitive to make a variable become unbound once it is bound, although
in principle there could be.
Jonathan
∂30-Jan-87 1302 Moon@STONY-BROOK.SCRC.Symbolics.COM MAKUNBOUND vs. special binding
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jan 87 13:02:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 58687; Fri 30-Jan-87 16:00:53 EST
Date: Fri, 30 Jan 87 16:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: MAKUNBOUND vs. special binding
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
cc: Common-Lisp@SAIL.STANFORD.EDU, Pavel.pa@XEROX.COM
In-Reply-To: <146816.870130.JAR@AI.AI.MIT.EDU>
Message-ID: <870130160053.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Fri, 30 Jan 87 12:21:21 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
(1) A variable is bound to
a value when evaluating that variable produces that value, and is
unbound when evaluating that variable is an error. (2) A special
variable is bound when its value has been saved upon entry to a
dynamic extent, and will be restored upon exit.
Just for the record, MIT Scheme solves this terminology problem by using
the terms "bound" and "unassigned". "Unbound" refers more or less to
(2) and "unassigned" to (1).
This sounds quite good to me. The only problem for Common Lisp is that all
uses of "bind" (actually "bound") in function names (as opposed to text of
the manual) are meaning (1). We just can't win.
∂30-Jan-87 1308 Moon@STONY-BROOK.SCRC.Symbolics.COM Documents
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jan 87 13:07:50 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 58691; Fri 30-Jan-87 16:06:30 EST
Date: Fri, 30 Jan 87 16:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Documents
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12275058967.BABYL@C.CS.CMU.EDU>
Message-ID: <870130160632.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 30 Jan 1987 10:12 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Do we want to clean up the "issues" document (removing some of my
editorial comments) and put that out as an X3J13 working document before
the February deadline?
I have yet to read that document, but even knowing nothing about what's in
it this seems like a good idea.
∂30-Jan-87 1337 @MIT-LIVE-OAK.ARPA,@PALLADIAN-JASPER.LCS.MIT.EDU,@WHITBY.PALLADIAN.COM:dfm@PALLADIAN-JASPER.LCS.MIT.EDU *terminal-io* or *standard-output*?
Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Jan 87 13:36:56 PST
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 26957; 30 Jan 87 16:38:13-EST
Received: from WHITBY.PALLADIAN.COM by JASPER.PALLADIAN.COM via INTERNET with SMTP id 26305; 30 Jan 87 16:19:51-EST
Date: Fri, 30 Jan 87 16:19 EST
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: *terminal-io* or *standard-output*?
To: common-lisp@sail.arpa
Message-ID: <870130161914.9.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
CLtL, page 382, refering to the output-stream argument for write and friends:
"If it is t, the value of the variable *terminal-io* is used."
Page 386, referring to format:
"If destination is t, the output is sent to the stream that is the value of the
variable *standard-output*"
Is this asymmetry intentional, and if so, why?
- Ben Hyde
Don Morrison
∂31-Jan-87 1250 FAHLMAN@C.CS.CMU.EDU [SAFIER%cgi.csnet: proposed modification to common lisp]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 31 Jan 87 12:43:52 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 31 Jan 87 15:44:32-EST
Date: Sat, 31 Jan 1987 15:44 EST
Message-ID: <FAHLMAN.12275381487.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: [SAFIER%cgi.csnet: proposed modification to common lisp]
Date: Sat, 31 Jan 87 14:25 ???
From: Scott <SAFIER%cgi.csnet at RELAY.CS.NET>
To: fahlman
Re: proposed modification to common lisp
Proposal: the following functions be modified to include a parameter which
specifies a package:
read, read-delimited-list, read-preserving-white-space
This additional parameter could either be a keyword argument, or an optional
argument. If the package is not specified, the current package (*package*)
will be used as the default.
Each of these three input functions can have the effect of creating symbols.
All other common lisp functions which create symbols (intern, gentemp) have
an optional package argument. It is inconsistent for some functions
which create symbols to have a package argument, and others not. Also, it is
burdensome for the common lisp programmar to create a local lexical
environment around input functions, simply to insure that any symbols created
during input are interned in the proper package. A package argument for these
input functions removes this burden.
This change is upward compatible. Current programs which rebind *package*
during input will behave exactly as before.
-Scott
∂01-Feb-87 1557 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Destructuring and &whole
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 1 Feb 87 15:57:29 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 51692; Sun 1-Feb-87 18:55:22 EST
Date: Sun, 1 Feb 87 18:54 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Destructuring and &whole
To: Stanley T. Shebs <shebs%utah-orion@UTAH-CS.ARPA>,
Hvatum@MIT-MULTICS.ARPA, common-lisp@sail.stanford.edu
In-Reply-To: <8701301637.AA10271@utah-orion.ARPA>,
<870130135555.226863@MIT-MULTICS.ARPA>
Message-ID: <870201185415.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Sigh. My example was not an attempt to say "&whole might be used for
detecting failed attempts at destructing." I don't know if that is how
people read my message, or how people read a reply to that message. In
any case, that's not what I meant. There are at least two uses for
non-top-level &whole that I can envision:
(1) To get a handle on the entire form for reporting purposes. The
destructuring may have succeeded (syntax) but the form may be in
error (semantics). The error reporter may want to show the entire
form that failed. My example tried to show that, but I failed to
articulate it.
(2) To get a handle on the entire form because you want the entire
form. The destructuring is an error checking mechanism (syntax),
which should signal an error (the closest CLtL appears to come is
top of pg151 in saying the construct is "in" error), as well as
giving you a parsed form of parts of the form for (semantic)
checking.
"That's just an example, ..." etc. What is the cost of stipulating that
&WHOLE should work at non-top level vs the cost of dearly wanting it
(after all, there is no LISP:DESTRUCTURING-BIND) and not having it?
∂02-Feb-87 0817 Masinter.pa@Xerox.COM Re: Documents
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Feb 87 08:17:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JAN 87 13:39:48 PST
Date: 30 Jan 87 13:42 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Documents
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Fri, 30 Jan 87 16:06 EST
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870130-133948-129@Xerox>
In addition to any revision of the Issues document, I hoped to produce
a "format" for submission of issues. I worked on this as a description
of what we would like to see from people who would like to see some
change. What I see is something like the following. This is not very
good writing, but maybe someone else could take this, edit it, and send
it back?
Report from the "Cleanup" committee.
We have begun on the process of going through various proposals to make
modifications to Common Lisp. The process is slow. We have categorized
some of the issues previously sent out by Guy, but, for the most part,
have not discussed them.
We would like to put these issues, and any further ones, in a standard
format where the important critera are specifically addressed. The
format is reproduced below. We welcome volunteers in helping in what
clearly looks like a time-consuming task.
FORMAT:
Issue: <name of issue. The chairman of the cl-cleanup will assign unique
IDs.>
Reference: <generally the pages of CLtL which describe the Common Lisp
feature being discussed.>
Description: <a description of the current situation, and what is wrong
with it. Why is there a change necessary?>
Category: <One of the following:
(1) clarification - a place where CLtL is ambiguous, and resolution of
the ambiguity is needed to allow programs to be portable
(2) mistake - a minor mistake in CLtL where it does not match the
intention of the authors,
(3) ommission - something that was accidentally left out of CLtL
(4) enhancement - a minor extension of Common Lisp necessary to allow
programs to be portable, or which cannot be implemented portably
>
Proposal: <Identify proposal as issue-name:proposal-name. Again, the
chairman of the cleanup committee will assign these, authors can assign
tenatitive IDs.>
<a description of what would change in CLtL to deal with the Issue.
More than one alternative proposal can be considered for a given issue;
each proposal will be labelled (issue-name:proposal-name)>
- - - - - - - - - - - - - - - -
Rationale:
This is the most important part. If more than one alternative proposal
is listed, answer the questions for *all* proposals. Be as brief as
possible.
<a> How does the proposal relate to existing practice? Do some/many/no
Common Lisp implementations already work this way?
<b> What is the cost of adopting this change (for developers of Common
Lisp systems)? I.e., what do implementations have to do to adopt it?
What is the change strategy? Is public domain code available, etc?
<c> What is the cost of *not* adopting this change (for future Common
Lisp programmers) ? I.e., how serious is the problem if it is just left
as is?
<d> What is the cost of converting existing code (for application
programmers with existing Common Lisp programs)? I.e., if this is an
incompatible change to Common Lisp, what is the estimate of the amount
of exisitng code that would be affected, and how hard is it to detect
what needs changing?
<e> Other esthetic critera: Are there arguments for cleanliness, ease of
explaination, etc. for this proposal?
Voting:
(Names of people followed by: Yes (agree to the proposal), No (disagree
with the proposal), Conditional (agree to the proposal with conditions,
e.g., resolution of another issue. Describe below.)
Discussion:
< any additional arguments, discussions, endorsements, etc. appended
here>
∂02-Feb-87 0935 Skef@think.com [SAFIER%cgi.csnet: proposed modification to common lisp]
Received: from ZARATHUSTRA.THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Feb 87 09:35:02 PST
Received: from Godot.Think.COM by zarathustra.think.com; Mon, 2 Feb 87 12:35:00 EST
Received: from blink by Godot.Think.COM via CHAOS; Mon, 2 Feb 87 12:34:53 EST
Date: Mon, 2 Feb 87 12:36 EST
From: Skef Wholey <Skef@think.com>
Subject: [SAFIER%cgi.csnet: proposed modification to common lisp]
To: common-lisp@sail.stanford.edu
In-Reply-To: <FAHLMAN.12275381487.BABYL@C.CS.CMU.EDU>
Message-Id: <870202123603.1.SKEF@BLINK.THINK.COM>
From: Scott <SAFIER%cgi.csnet at RELAY.CS.NET>
Re: proposed modification to common lisp
Proposal: the following functions be modified to include a parameter which
specifies a package:
read, read-delimited-list, read-preserving-white-space
This additional parameter could either be a keyword argument, or an optional
argument. If the package is not specified, the current package (*package*)
will be used as the default.
[...] Also, it is
burdensome for the common lisp programmar to create a local lexical
environment around input functions, simply to insure that any symbols created
during input are interned in the proper package. A package argument for these
input functions removes this burden.
[...]
Three reactions:
1. These functions already have a just-barely managable number of
optional parameters, and adding another would push them over the
edge.
2. Converting them to use all keyword args might have been a good
idea three or four years ago, but isn't feasible now.
3. This functionality can be easily implemented at user level, with
a few macros.
By the way, Read-From-String probably belongs in the list above. It
already takes both optional and keyword arguments, so extending it along
with the others complicates (or simplifies, depending on how you look at
it) the situation a bit.
But how about this: introduce a new function, Parse, which is to Read as
Write is to Print -- a big fancy general-purpose I/O function that takes
all imaginable keyword arguments and Does The Right Thing. Whether or
not it would preserve whitespace would be one argument. We could either
leave Read-Delimited-List out of this, or add Parse-Delimited-List as
well.
--Skef
∂02-Feb-87 1137 shebs%utah-orion@utah-cs.arpa Re: Parse as General Case of Read
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 2 Feb 87 11:36:20 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA27773; Mon, 2 Feb 87 12:38:02 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA13219; Mon, 2 Feb 87 12:37:58 MST
Date: Mon, 2 Feb 87 12:37:58 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8702021937.AA13219@utah-orion.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Re: Parse as General Case of Read
I second the motion to have a parse function that takes a bunch of keywords...
PARSE &key :stream :eof-error-p :eof-value :recursive :preserve-whitespace
:delimited :float-format :base :suppress :readtable
Easy to implement for existing systems, very clean for new systems, and is
consistent with WRITE. If PARSE is objectionable due to excessive numbers
of keywords, then so is WRITE...
stan
∂02-Feb-87 1743 kempf%hplabsc@hplabs.HP.COM LALR Parser Generator Available?
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 2 Feb 87 17:43:36 PST
Received: from hplabsc by hplabs.HP.COM ; Mon, 2 Feb 87 08:13:51 pst
Received: by hplabsc ; Mon, 2 Feb 87 08:10:41 pst
Date: Mon, 2 Feb 87 08:10:41 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8702021610.AA24275@hplabsc>
To: common-lisp@sail.stanford.edu
Subject: LALR Parser Generator Available?
Is anyone aware of a LALR parser generator written in Common
Lisp which is available? Public domain or university software
with source is preferred, but information about products would
also be appreciated. Please reply via mail (kempf@hplabs.hp.com),
and apologies in advance if this mailing list is not deemed
appropriate for such requests. Thanks.
Jim Kempf kempf@hplabs.hp.com
PS: I am aware of the SLR parser generator written in PCLS
(Portable Common Lisp Subset) from Utah.
∂02-Feb-87 1836 FAHLMAN@C.CS.CMU.EDU Just to clarify...
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Feb 87 18:35:30 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 2 Feb 87 21:36:27-EST
Date: Mon, 2 Feb 1987 21:36 EST
Message-ID: <FAHLMAN.12275969850.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Just to clarify...
The fact that I forwarded Scott Safier's suggestion didn't imply that I
was endorsing it. In fact, I tend to agree with Skef on this: these
functions already have too many arguments, and if you need temporary
package rebinding, that is easily accomplished with a user-defined
macro.
For the record, it is legitimate to rasie new issues directly on the
Common Lisp bboard. I long ago gave up the attempt to focus this forum
on a small number of issues. But please bear in mind that mail sent to
Common Lisp goes to a *LOT* of people, so think about your message
before you send it.
-- Scott
∂02-Feb-87 2300 edsel!bhopal!jonl@navajo.stanford.edu Rational Infinities
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Feb 87 22:58:49 PST
Received: by navajo.stanford.edu; Mon, 2 Feb 87 22:57:36 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA07923; Mon, 2 Feb 87 22:31:25 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA06863; Mon, 2 Feb 87 22:34:55 PST
Date: Mon, 2 Feb 87 22:34:55 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8702030634.AA06863@bhopal.edsel.com>
To: navajo!Common-Lisp%sail@navajo.stanford.edu
Cc: bhopal!jonl@navajo.stanford.edu
Subject: Rational Infinities
Some CL implementations don't use IEEE floating point, and typically
don't have any way to represent floating-point infinity. Would there
be any negative consequences of allowing forms like
1/0 and -1/0
to be legitimate ratios?
-- JonL --
∂03-Feb-87 0044 TOURETZKY@C.CS.CMU.EDU Re: [Masinter.pa: Re: Documents]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Feb 87 00:44:29 PST
Received: ID <TOURETZKY@C.CS.CMU.EDU>; Tue 3 Feb 87 03:45:46-EST
Date: Tue 3 Feb 87 03:45:46-EST
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: Re: [Masinter.pa: Re: Documents]
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870202-172433-1341@Xerox>
Message-ID: <12276037089.25.TOURETZKY@C.CS.CMU.EDU>
Thanks for the instructions on how to supply a more detailed version of my
proposal. I don't like the issue name MAKE-ARRAY-DISPLACED-UNNECESSARY,
though. I think a better name for this issue would be
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS.
Should I use that name in my formal proposal?
-- Dave
-------
∂03-Feb-87 0935 RPG From Japan
∂03-Feb-87 0323 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET From Japan
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Feb 87 03:22:59 PST
Received: from utokyo-relay by csnet-relay.csnet id ad20561; 3 Feb 87 3:06 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA17303; Tue, 3 Feb 87 16:11:35+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA07859; Tue, 3 Feb 87 16:02:53+0900
Date: Tue, 3 Feb 87 16:02:53+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8702030702.AA07859@ccut.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@ZARATHUSTRA.THINK.COM,
ida%u-tokyo.junet@RELAY.CS.NET, mathis@ADA20.ISI.EDU, rpg@SU-AI.ARPA
Subject: From Japan
Dear Sirs,
I got 'push-backs' from industries as to JIS standardization.
Several of the JIS members mensioned me their desire that JIS should be
more close to ANS Common Lisp.
(personally I feel very happy).
So, the status in japan I mensioned in my last mail is slightly changing.
Dear Bob,
I seems to be unable to send you a document on the japanese status as of now.
But, I will carry it to Palo Alto and I am ready to explain our status
at X3 meeting.
Anyway, I am compiling the report on the full two years activities
on Common Lisp. It include the stories on O.O.WG, SubsetWG, KanjiWG,
and basic invistigations, ...
Masayuki
"ida%utokyo-relay.csnet"@RELAY.CS.NET/su
Reports
Prof. IDA:
Thank you for your reports on the progress in Japan on standarization.
I look forward to hearing your report on the Japanese reaction to the
issue of the function cell/value cell in Palo Alto.
-rpg-
∂03-Feb-87 1230 wilensky%larch.Berkeley.EDU@BERKELEY.EDU Binding, etc.
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 3 Feb 87 12:29:39 PST
Received: by ucbvax.Berkeley.EDU (5.53/1.20)
id AA27352; Tue, 3 Feb 87 11:04:25 PST
Received: by larch (3.2/5.17)
id AA16334; Tue, 3 Feb 87 11:02:35 PST
Date: Tue, 3 Feb 87 11:02:35 PST
From: wilensky%larch.Berkeley.EDU@BERKELEY.EDU (Robert Wilensky)
Message-Id: <8702031902.AA16334@larch>
To: Pavel.pa@xerox.com, Moon@stony-brook.scrc.symbolics.com
Subject: Binding, etc.
Cc: Common-Lisp@sail.stanford.edu
(I sent this a while ago, but I believe the mail system ate it. Apologies
in advance if you received it already).
Some time ago I sent around a flame on the issue of the ``binding''
terminology in Common LISP. My contention is that the whole notion of
binding as used in the LISP community is not particularly coherent. The
best solution to the many problems is to eliminate this usage altogether.
While this may seem radical at first, I believe it is the only consistent
solution, and the result is actually quite simple.
Basically, the gripe is that the usage of the terms ``binding'', ``bound'',
``bind'', etc. confuse implementation issues with semantic issues (more on
this below). My proposal is to say that applying a lambda, etc. causes a
new VARIABLE to be created corresponding to each formal parameter (as
opposed to a new binding for a variable). It also happens to ASSIGN a value
to that variable. In general, variables may or may not have assignments,
and SETQ changes assignments.
Rather than talk about bindings, etc., we now talk about how occurrences of
symbols refer to variables. For example, there is no longer a notion of a
``free variable'', but merely a free occurrence of a symbol. The rules
about special variables are rules about which variable a free occurrence of
a symbol refers to. Similarly, using a symbol at the top level to refer to
a variable refers to the global variable associated with that symbol.
Note that the only change in Common LISP (other than the documentation) that
needs to be changed to accommodate my proposal to rename some misnamed
functions. For example, ``boundp'' (which has nothing whatsoever to do with
bindings, under any interpretation) should be called ``assignp'';
``makunbound'' becomes ``makunassigned'' (or, even more daringly,
``make-unassigned''). There are a few others...
I wrote Common LISPcraft using this terminology, and I believe it worked
very well.
Here's a copy of my old flame, fyi:
----------------------------------------
There appears to be considerable terminological confusion in Commmon LISP.
Here are two examples:
(1) The use of the terms ``binding'', ``bound'' and ``unbound''.
On p. 55 we are told variable can be ``assigned to, as by `setq' or bound,
as by `let'. '' However, a binding is defined as a particular parameter
instance (p. 36). Moreover, a special variable (and only a special
variable) can be ``unbound''. It is also rather hard to avoid saying that
a special variable is ``bound'' when it has a value, as ``boundp'' will
return true in this case.
Unfortunately, these meanings are in conflict. For example, they allow for
the case in which a variable is ``bound'' but has no ``binding'' (namely,
when the reference is to the global value); the variable can be ``unbound'',
but have a binding (as you point out, when it is ``bound'', but valueless.)
If you simply refuse to say that a variable without any bindings is bound
(even though ``boundp'' of it is true), you are then committed to saying
that it is not `bound'', not ``unbound'', and has no ``binding'' (although,
of course, it has a perfectly fine and accessible value). In addition, a
``bound variable'' appears to mean a variable that currently has a binding
(as in, ``a variable bound by `let' ''), although, of course, such a bound
variable may very well be ``unbound''.
In addition, there appears to be confusion as to whether a variable or a
binding is something that is referenced, etc. For example, p. 37 talks
about the scope and extent of special bindings, whereas p. 38 talks about
the scope and extent of special variables. it is unclear what a reference
to a variable that happens to be a parameter might be, other than a
reference to its current binding, since this is an fact the particular
instance of that paramater that is in force. For example, p. 55 talks about
``the reference ... to the variable specified by the binding''. It is not
clear how a particular instance of a parameter can specify a variable. Nor
would this seem desirable. If two different invocations of the same
function are considered to have the same variables but with different
bindings, then one would not want to reference any variable, but rather, the
current bindings of those variables.
I could go on, but I think you get the point.
Here are some suggestions:
Drop the notion of binding altogether. I think this is really an old
implementation artifact. Instead, say that every APPLICATION of a lambda
form creates new variables for its formal parameters. Also, every symbol
has a global variable associated with it. A variable may have a value, or
it may be valueless. A variable has an extent and a scope.
Introduce the function ``assignedp'', which meets the current description of
``boundp''. ``setq'' changes the value of a variable through
``assignment''. Lambda application creates a new variable and assigns it a
value.
(2) Special Form Terminology
A special form is defined as a form beginning with one of the symbols
appearing in Table 5-1. However, p. 57 states that ``The set of special
forms is fixed in Common LISP'' and that ``The set of special forms in
Common LISP is purposely kept very small''. Of course, these claims are
both false. There are an infinite number of special forms in Common LISP.
What is finite and small is the set of symbols that designate special forms.
These are referred to in Table 5-1 as the ``names'' of special forms.
Ugh. I propose the following terminology: Leave the definition of special
forms alone. Call the objects referred to by the symbols that designate
special forms ``special functions''. Call the objects referred to by
symbols that invoke macro definitions ``macro functions''. Call everything
else a ``normal'' function. These are the unmarked case, analogous to the
lack of a compelling name for non-``special'' variables.
This terminology appears to be consistent with ``symbol-function'', which
may return something ``representing a special form (sic) or macro.''
∂03-Feb-87 1351 ELIOT%cs.umass.edu@RELAY.CS.NET Rational Infinity
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 3 Feb 87 13:51:10 PST
Received: from cs.umass.edu by csnet-relay.csnet id ax05944; 3 Feb 87 15:21 EST
Date: Tue, 3 Feb 87 13:42 EDT
From: ELIOT%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SU-AI.ARPA
Subject: Rational Infinity
X-VMS-To: CSNET%"common-lisp@su-ai.arpa"
Division by zero should signal an error whenever possible.
Defining it to silently return something would make debugging
numerical code more difficult. I have found some very obscure
bugs as a result of division by zero traps.
∂03-Feb-87 1737 DLA@DIAMOND.S4CC.Symbolics.COM REMF and REMPROP
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 3 Feb 87 17:37:12 PST
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52704; Tue 3-Feb-87 20:35:37 EST
Date: Tue, 3 Feb 87 20:35 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: REMF and REMPROP
To: common-lisp@SU-AI.ARPA
cc: DLA@DIAMOND.S4CC.Symbolics.COM
Message-ID: <870203203541.8.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>
I would like some clarification on the definition of REMF and REMPROP.
Both of these are documented by CLtL to "destructively splice the
property list" to remove the value. The nature of the destructive
splicing is not specified.
The question is, is it legal for REMF and REMPROP to remove the pointer
to the value (i.e., by setting it to NIL) as part of this operation?
This is advantageous to some garbage-collection schemes, which
have an easier time collecting the value pointed to if it is
indeed garbage after the REMPROP.
The disadvantage is that the behavior of REMPROP would be undefined
when property lists are shared. For example, consider the following
sequence:
(SETQ *FOO* (LIST :A '(A GARBAGE) :B '(B GARBAGE)))
(SETQ *ORIGINAL-FOO* *FOO*)
(REMF *FOO* :A)
*FOO*
*ORIGINAL-FOO*
One might expect the last form to return (:A (A GARBAGE) :B (B GARBAGE)),
whereas if REMF is allowed to bash the pointer to assist garbage
collection, the last form would return (:A NIL :B (B GARBAGE)).
Alternatively, would it be legal for REMF to pull the indicators and
values to the front of the list? In that case, *ORIGINAL-FOO* would end
up equal to (:B (B GARBAGE)).
∂03-Feb-87 1912 jbarnett@NRTC.ARPA Re: Rational Infinity
Received: from NRTC.ARPA by SAIL.STANFORD.EDU with TCP; 3 Feb 87 19:08:42 PST
Date: Tue, 3 Feb 87 19:08:31 PST
From: Jeff Barnett <jbarnett@NRTC.ARPA>
To: ELIOT%cs.umass.edu@relay.cs.NET
cc: common-lisp@sail.stanford.EDU
Subject: Re: Rational Infinity
I think it is very interesting that you find that traping division by zero
helps find some very obscure bugs. It's probably also true that you think
it is easier to prove and disprove various things about your programs via
an appeal to formal mathematical models of numbers. Why this is interesting
is that in the old days, I made the same comments when LISP systems quit
traping when we took CAR and CDR of NIL! When they did, it helped me find
obscure bugs and I was able to prove and disprove things about my programs
via an appeal to formal mathematical models of S-EXPRESSIONS. I gave up this
line of argument because nobody would listen and I got old an lazy a came
out of the closet and had to admit I liked using what I still consider to
be an atrocious hack.
About floating point infinity and IEEE standards, I must admit that
it's a great thing. I think that it would be sad to not make them part of the
CL standard--if you think standards are a reasonable venture, they why not
include a very good (and very well thought out) one in another. Let me
change the word sad to foolish. Numerical calculations that must deal with
ideal points are hard to code period. There is no similarity in code that
uses IEEE standard and that which doesn't. If its available, it's too good
to not use. Insisting on the standard would force some implementors to
do extra work I know. But I think it would be a good idea.
One of the nice things about LISP and its derivitives is that it
makes it easy and possible to code our ideas and models rather than do
everything by total hackery. Hell, even a poor man can pretend to be a
scholar instead of a code jockey. If you don't think the IEEE standard
solves an important problem, try coding some floating point computations
and, before you do each operation, determine (1) if this operation will
over (underflow) the size of this machines representation and (2) if any
previous operation ran into trouble, what to do in lieu of this one.
I think one iteration of this will make you kiss the IEEE standards with
ideal points. For the record, my coding experience using hardware or
software where it was available has convinced that it reduces the coding
by a factor of 20 in routines where I cared about these things.
Jeff
∂04-Feb-87 0429 cugini@icst-ecf Binding terminology
Received: from ICST-ECF.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 04:28:58 PST
Date: 4 Feb 87 07:09:00 EST
From: "CUGINI, JOHN" <cugini@icst-ecf>
Subject: Binding terminology
To: "common-lisp" <common-lisp@sail.stanford.edu>
Reply-To: "CUGINI, JOHN" <cugini@icst-ecf>
> From: wilensky%larch.Berkeley.EDU@BERKELEY.EDU (Robert Wilensky)
>
> Some time ago I sent around a flame on the issue of the ``binding''
> terminology in Common LISP. My contention is that the whole notion of
> binding as used in the LISP community is not particularly coherent. The
> best solution to the many problems is to eliminate this usage altogether.
> While this may seem radical at first, I believe it is the only consistent
> solution, and the result is actually quite simple....
I'd like to add my hearty agreement with this proposal. I distinctly
remember muttering "what the hell are they talking about?" when I
first tried to understand scoping, binding, variables, etc by reading
CLtL (of course NOW I understand perfectly...).
There's no reason why CL should adopt a peculiar terminology to
explain concepts for which accepted terms already exist in other
languages. Just frinstance, no other language I know of that has
recursion speaks of "different bindings of the same variable" to
explain what's going on with the parameter list of a recursively
invoked function. The CL terminology conjures up the image of one
object with a changeable property, rather than of different objects,
each of which is referred to by the same name at different times.
Whether this is worth the implied documentation overhaul is a matter of
judgment. I would say that at least if the "fix-up CLtL" subcommittee
is going to do a more or less complete re-write, then we should fold
this in.
John Cugini <Cugini@icst-ecf>
------
∂04-Feb-87 0627 Cassels@STONY-BROOK.SCRC.Symbolics.COM Rational Infinity
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 06:27:18 PST
Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 61678; Wed 4-Feb-87 09:26:11 EST
Date: Wed, 4 Feb 87 09:27 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Rational Infinity
To: ELIOT%cs.umass.edu@RELAY.CS.NET, common-lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Feb 87 12:42 EST from ELIOT%cs.umass.edu@RELAY.CS.NET
Message-ID: <870204092720.8.CASSELS@KRYPTON.SCRC.Symbolics.COM>
Date: Tue, 3 Feb 87 13:42 EDT
From: ELIOT%cs.umass.edu@RELAY.CS.NET
Division by zero should signal an error whenever possible.
Defining it to silently return something would make debugging
numerical code more difficult. I have found some very obscure
bugs as a result of division by zero traps.
The existence of infinite rational objects and how they come about are
two separate issues. If there were a Common Lisp error system, you
would want something like:
- Division by zero signals an error. (Note that 0/0 is different from
non-zero/0.)
- The user has an option when the error is signalled (in the non-zero/0
case) to use an "infinite" result.
- There is a form which turns off such error signalling within its
body, so that infinities are produced for division by zero, without
user intervention.
- There is a way for the programmer or user to explicitly enter an
infinite object into the system (by typing it).
- When an infinite object appears in a computation, the "mathematically
correct" thing happens. [The IEEE floating-point rules are one
possible definition of "correct".]
So infinities only appear under explicit programmer or user control.
Thus you get the best of both trapping and non-trapping worlds. The
Symbolics system handles IEEE floating-point divide-by-zero this way.
[Hard-core IEEE standards fanatics will point out that the default is
supposed to be that division doesn't trap, but just quietly returns an
infinity. We chose to make trapping be the default for all exceptions
except inexact-result.]
Note that it depends on what sort of calculation you're doing whether
infinity is an appropriate answer or not. One of the reasons that
rational infinities aren't in Common Lisp yet is that there is some
debate about whether rational infinity is affine (signed) or projective
(unsigned).
∂04-Feb-87 0649 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Rational Infinity
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 4 Feb 87 06:45:40 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52788; Wed 4-Feb-87 09:44:04 EST
Date: Wed, 4 Feb 87 09:46 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Rational Infinity
To: ELIOT%cs.umass.edu@RELAY.CS.NET, Jeff Barnett <jbarnett@NRTC.ARPA>,
common-lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Feb 87 12:42 EST from ELIOT%cs.umass.edu@RELAY.CS.NET,
The message of 3 Feb 87 22:08 EST from Jeff Barnett <jbarnett@NRTC.ARPA>
Message-ID: <870204094650.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
I assume that if this becomes a real proposal, there would be
trap-enable equivalents for rational infinities and rational NaNs
analogous to IEEE trap enables for overflow, underflow, etc. For
example, one possible syntax might be
(with-rational-trap-enables ((:divide-by-zero :infinity))
(/ a b))
might return 1/0 or -1/0 silently, while
(with-rational-trap-enables ((:divide-by-zero :error))
(/ a b))
would signal an error. In systems that have condition handling and/or
proceed options, the program and/or user could decide to use +-1/0 if
that seemed like a good thing to do at the time.
Once generated (i.e., in the dataflow of the program), rational
infinities don't cause further traps unless you divide two infinities or
multiply an infinity by 0. For example, (sqrt 1/0) would return 1/0,
(* 1/0 positive-number) would return 1/0, etc.
∂04-Feb-87 0724 smh@EMS.MEDIA.MIT.EDU Re: LALR Parser Generator Available?
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 07:24:39 PST
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA03385; Wed, 4 Feb 87 10:07:55 EST
Date: Wed, 4 Feb 87 10:07:55 EST
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8702041507.AA03385@EMS.MEDIA.MIT.EDU>
To: kempf%hplabsc@hplabs.HP.COM
Subject: Re: LALR Parser Generator Available?
Cc: common-lisp@sail.stanford.edu
The good news: I happen to have exactly such a beast. It is
essentially an analog of YACC written in portable Common Lisp.
Grammar rules may be coded as Lisp sexprs, or through a front end
translator providing YACC-like syntax. (The front end is written in
itself, naturally.)
The bad news: The software is proprietary, owned by a former employer.
I'm trying to negotiate an arrangement whereby it could be released.
The fact that from time to time someone expresses interest increases
the chance it will happen, but I'm afraid the process will take
months, not weeks.
∂04-Feb-87 0831 FAHLMAN@C.CS.CMU.EDU REMF and REMPROP
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 08:31:30 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Feb 87 11:33:07-EST
Date: Wed, 4 Feb 1987 11:33 EST
Message-ID: <FAHLMAN.12276384296.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: REMF and REMPROP
In-reply-to: Msg of 3 Feb 1987 20:35-EST from David L. Andre <DLA at DIAMOND.S4CC.Symbolics.COM>
In reply to: David L. Andre <DLA at DIAMOND.S4CC.Symbolics.COM>
Both of these are documented by CLtL to "destructively splice the
property list" to remove the value. The nature of the destructive
splicing is not specified.
The question is, is it legal for REMF and REMPROP to remove the pointer
to the value (i.e., by setting it to NIL) as part of this operation?
I guess this is yet another thing that needs to be clarified. Here are
a couple of opinions that may be of use in the meantime:
First, it is in the nature of property lists that they get destructively
modified, and it is a remarkably bad idea to write code of the sort you
describe that shares this top-level list structure. Anyone who writes
code that does this should change the code to something sensible and not
quibble about what is legal.
On the other hand, it seems to me that it violates the (implicit)
contract of a destructive operation like REMPROP to take the excised
piece of list and chop it up into little pieces or to re-use the list
cells that it snipped out. The fact that some built-in operation makes
a destructive change does not necessarily give this operation the right,
or the necessary global perspective, to decide what is garbage and what
is not. Sharing is possible in Common Lisp, and it is the garbage
collector's job to decide what cons cells can safely be recycled.
Destructive operations should do what they are documented to do, and no
more.
I grant that CLtL does not explicitly prohibit the kind of operation you
are describing, but I submit that this is because it never occurred to
us that anyone would want to do such a thing.
-- Scott
∂04-Feb-87 1120 DALY@IBM.COM
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 4 Feb 87 11:17:57 PST
Date: 4 February 1987, 13:08:43 EST
From: "Timothy P. Daly" <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <020487.130843.daly@ibm.com>
Subject:
Subject: defstruct question
How can I define data structures that are pairs using defstruct?
How can I define data structures that contain pairs? What I want
to say is:
(defstruct (name (:type cons)) a b)
intending to create a thing of the form (name-a . name-b)
how can I name subfields?
(defstruct name (a :type cons :field-names '(kar kdr)))
intending to create a thing like
#((name-a-kar . name-a-kdr))
Tim Daly
DALY@IBM.COM
∂04-Feb-87 1138 fateman@renoir.Berkeley.EDU Re: Rational Infinity
Received: from RENOIR.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 11:37:06 PST
Received: by renoir.Berkeley.EDU (5.57/1.16)
id AA28650; Wed, 4 Feb 87 11:35:39 PST
Date: Wed, 4 Feb 87 11:35:39 PST
From: fateman@renoir.Berkeley.EDU (Richard Fateman)
Message-Id: <8702041935.AA28650@renoir.Berkeley.EDU>
To: DCP@quabbin.scrc.symbolics.com, common-lisp@sail.stanford.edu,
jbarnett@nrtc.arpa
Subject: Re: Rational Infinity
there are also complex numbers and complex infinities of both
rational and floating-point forms in CL. These must be dealt with.
The with-rational-trap-enables ... proposal suggests that
trap enabling should have dynamic scope. Do you mean this?
∂04-Feb-87 1250 FAHLMAN@C.CS.CMU.EDU REMF and REMPROP
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 12:48:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Feb 87 15:49:05-EST
Date: Wed, 4 Feb 1987 15:48 EST
Message-ID: <FAHLMAN.12276430880.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David C. Plummer" <DCP@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: REMF and REMPROP
In-reply-to: Msg of 4 Feb 1987 12:13-EST from David C. Plummer <DCP at QUABBIN.SCRC.Symbolics.COM>
I can interpret parts of that paragraph two ways. One way (the way I
don't want to) is that REMF can go off and bash the value. That's not
what Andre was suggesting.
I don't see how you could read this interpretation into what I said, but
it doesn't matter. I think we all agree that it is not legal for REMF
or REMPROP to do anything destructive to the keys and values it removes
from the property list.
What Andre was asking, I thought, was whether it was legal to chop up or
recycle the cons cells that had been part of the backbone of the property
list. My opinion was that this is not legal -- REMPROP and REMF should
do only as much destructive alteration as is necessary to remove the
specified key and value from the list.
-- Scott
∂04-Feb-87 1435 Moon@STONY-BROOK.SCRC.Symbolics.COM Binding terminology
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 14:31:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 62349; Wed 4-Feb-87 17:29:53 EST
Date: Wed, 4 Feb 87 17:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Binding terminology
To: "CUGINI, JOHN" <cugini@ICST-ECF.ARPA>
cc: common-lisp <common-lisp@sail.stanford.edu>
In-Reply-To: The message of 4 Feb 87 07:09 EST from "CUGINI, JOHN" <cugini@icst-ecf>
Message-ID: <870204172926.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 4 Feb 87 07:09:00 EST
From: "CUGINI, JOHN" <cugini@icst-ecf>
....no other language I know of that has
recursion speaks of "different bindings of the same variable" to
explain what's going on with the parameter list of a recursively
invoked function. The CL terminology conjures up the image of one
object with a changeable property, rather than of different objects,
each of which is referred to by the same name at different times.
Part of this is because few other languages have dynamic binding.
Dynamic variables really are one object with a changeable property.
Lexical variables, on the other hand, are separate objects referred to
by the same name in separate scopes.
∂04-Feb-87 1843 Miller.pa@Xerox.COM Re: Binding terminology
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Feb 87 18:43:00 PST
Received: from Salvador.ms by ArpaGateway.ms ; 04 FEB 87 18:28:47 PST
Date: 4 Feb 87 18:05 PST
Sender: Miller.pa@Xerox.COM
From: Mark S. Miller.PA <Miller.PA@Xerox.COM>
Subject: Re: Binding terminology
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 4 Feb 87 17:29 EST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cugini@ICST-ECF.ARPA, common-lisp@sail.stanford.edu,
VulcanCore↑.pa@Xerox.COM
Message-ID: <870204-182847-1431@Xerox>
Date: Wed, 4 Feb 87 17:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Dynamic variables really are one object with a changeable
property. Lexical variables, on the other hand, are separate
objects referred to by the same name in separate scopes.
Only if your conceptual model corresponds to shallow binding. (sorry
for introducing an orthogonal use of "binding" into this discussion) My
conceptual model for dynamic variables corresponds to deep binding. In
shallow binding, new dynamic bindings (as introducted by LET) assign to
a variable and remember to undo this assignment on exit from the LET.
In deep binding, LETs introduce new name-variable associations.
Specifically, I think of CommonLisp as if it were compiled into a
lexically-scoped-only lisp (LexicalLisp) as follows:
Every CommonLisp function is compiled into a LexicalLisp function that
has an additional parameter: a dynamic naming environment. This is
much like compiling a call-return lisp into a call only lisp by
introducing an additional continuation parameter. The dynamic naming
environment is an object that associates symbols with variables
("variables" in the new suggested meaning).
In the absence of any LETs, etc. of special variable names in a function
body, all calls in a function would be compiled to pass on the same
dynamic naming environment received by this function. What a LET form
does is to create a new environment consisting of the old environment +
a new contour associating names (symbols) with new variables. This
environment is then used within the body of the LET as the current
dynamic naming environment. References to special variable names are
compiled into requests to the current dynamic naming environment to
lookup the variable associated with this name.
This model is conceptually simple, you don't have to worry about undoing
bindings (or assignments) when you leave dynamic extents (including
abnormal exits), there is no problem with introducing parallelism, and
we could consistently use the new terminology without guilt. It is also
a valid description of what it is that's being implemented by the
typical stack lookup implementation of deep binding (such as Interlisp).
I suggest that our terminology reflect this model, and that shallow
binding only be considered a particular way it can be implemented.
----- MarkM
∂04-Feb-87 1916 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Binding terminology
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Feb 87 19:15:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 62526; Wed 4-Feb-87 22:13:03 EST
Date: Wed, 4 Feb 87 22:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Binding terminology
To: Pavel.pa@Xerox.COM, Miller.PA@XEROX.COM
cc: Common-Lisp@sail.stanford.edu
In-Reply-To: <870204-175046-1399@Xerox>
Message-ID: <870204221242.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I hate to bother the whole mailing list with this, but it seems
necessary, since I've been mistaken as saying something biased
towards shallow binding.
I don't think you understood what I said. What I said has nothing to do
with implementation. Dynamic variables are changeable because when a
dynamic variable is referenced, that reference can refer at different
times to name/value associations created at different places in the
program. This is more changeable than lexical variables, where a given
reference always refers to a name/value association created at the same
place in the program.
∂04-Feb-87 2133 TOURETZKY@C.CS.CMU.EDU SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Feb 87 21:31:02 PST
Received: ID <TOURETZKY@C.CS.CMU.EDU>; Thu 5 Feb 87 00:31:34-EST
Date: Thu 5 Feb 87 00:31:33-EST
From: Dave.Touretzky@C.CS.CMU.EDU
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <12276526020.28.TOURETZKY@C.CS.CMU.EDU>
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Reference: Chapter 14 (Sequences) of CLtL. Also, page 51 (COERCE).
Description: Common Lisp provides many useful operations on lists and vectors
which ought also to apply to arrays. For example, one can FILL a vector with
0's, but not an array. One can REPLACE the contents of one vector with
another, but one can't do this for arrays. One can verify that EVERY element
of a vector has some property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up all the
useful tools CLtL provides for manipulating sequences, even though there is no
intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work on
arrays. The designers of Common Lisp may have felt that there was no clear way
to consistently extend sequence functions to cover arrays. In this note I
propose a very low cost, uniform extension that solves this problem.
Category: Enhancement.
Proposal: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:TREAT-ARRAYS-AS-DISPLACED-VECTORS
Common Lisp already provides a facility called "displaced arrays" which can be
used to overlay one array on top of a portion of another, even if the two are
of different ranks, so that the two share storage. I propose the following:
built in functions that take an argument of type "sequence" (the functions in
chapter 14 of CLtL), and that could sensiby be applied to arrays, should be
extended to handle arrays by treating them as displaced vectors. There are
three cases to consider. Suppose A is a 3x2x7 vector.
Case I: sequence functions whose results aren't sequences, or whose results are
EQ to their input. LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY,
NOTEVERY, REDUCE, SEARCH, MISMATCH, FILL, REPLACE, NSUBSTITUTE, NREVERSE, SORT.
All of these would be extended to access array elements as if they were
accessing a vector displaced to that array. For example, (LENGTH A) should
return 42, and (ELT A 7) should return A[0,1,0]. :START and :END keywords
would be interpreted relative to the vector, as would the results returned by
POSITION and SEARCH. Note that simply extending LENGTH, ELT, and the SETF
expander for ELT would have the side effect of extending the remaining
functions in this list, assuming they're written in the obvious way.
Case II: sequence functions whose result should be the same shape as but not
necessarily EQ to their argument. There are just three of these: SUBSTITUTE,
REVERSE, and MAP. Actually, MAP should be able to return any shape array
the user wants. All three functions could be defined in terms of an
extended MAKE-SEQUENCE function -- see below.
Case III: sequence functions that cannot return results that are the same shape
as their arguments when their arguments are arrays. SUBSEQ, COPY-SEQ,
CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
These functions should remain undefined for arrays.
Also, COERCE should be modified so that it can coerce arrays to vectors and
vice versa. In keeping with p.51 of CLtL, it should be an error if the result
type has a different number of elements than the object being coerced. And
MAKE-SEQUENCE should be modified to accept array descriptions as well as vector
descriptions. Then a SUBSTITUTE function that worked for arrays could be
written as follows:
(defun substitute (new-item old-item sequence &key ...)
(let ((result (make-sequence (type-of sequence))))
(dotimes (i (length sequence) result)
(setf (elt result i) (if (eql (elt sequence i) old-item) new-item
(elt sequence i))))))
Note that EQUALP should not treat arrays as vectors. It is not a sequence
function, and it already has a well-defined behavior for arrays. To test
whether the arrays A and B, of different shapes, have the same elements, one
would write (AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).
Rationale:
<a> This proposal would expand rather than interfere with existing practice.
<b> Since displaced arrays are already part of Common Lisp, the cost of the
proposed change would be very low.
<c> If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops every
time they want to perform an array operation equivalent to FILL, REPLACE,
REDUCE, etc., or else they can build displaced vectors by hand and pass them to
the sequence functions when necessary. I have been using the latter approach
in my applications code, but I really dislike it.
<d> This change is entirely upward compatible. Existing code will run
without modification.
<e> Esthetics: this proposal extends sequence functions to cover arrays while
neatly avoiding the temptation to turn Common Lisp into a half-baked APL.
Instead of trying to provide a full set of array handling primitives (which
would be needed to take arbitrary k-dimensional slices out of n-dimensional
arrays, or to apply an operator across a specific dimension of a
multidimensional array), it requires just one rule: treat arrays as displaced
vectors. The sequence functions become more useful, their behavior remains
intuitive, and the cost of the extension is very low.
-------
∂04-Feb-87 2139 RPG Re: Reports
∂04-Feb-87 1327 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Re: Reports
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 4 Feb 87 13:25:49 PST
Received: from utokyo-relay by csnet-relay.csnet id aa23021; 4 Feb 87 13:43 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA24714; Thu, 5 Feb 87 01:30:46+0900
Received: by ccut.u-tokyo.junet (4.12/6.1Junet)
id AA09604; Thu, 5 Feb 87 01:12:34+0900
Date: Thu, 5 Feb 87 01:12:34+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Message-Id: <8702041612.AA09604@ccut.u-tokyo.junet>
To: RPG%SU-AI.ARPA%u-tokyo.junet@RELAY.CS.NET,
ida%utokyo-relay.csnet%csnet-relay.csnet@RELAY.CS.NET
Subject: Re: Reports
Dear Dr. Gabriel;
OK, I will also talk about the stories on Lisp1/Lisp2 issue in japan.
Totallyspeaking, most of us think "If the language is called Lisp,
it must have separate spaces", as you quoted in your article.
But, Hlisp which was designed by Prof. Goto, employed a single name space policy.
Several PC based Lisp (and Common Lisp) also have single name space policies.
Japanese made PC-Common Lisps including my one for the base for CL/Core
have single name space for space efficiency sake and have possibilities
to suffer from the CAR evaluation problems for forms, which were discussed
in commonlisp@su-ai, triggered by mike of Goldhill or someone.
But in japan, many users think the CAR of form should be a symbol,
so fortunately almost noone tried to attempt to write a code
which need the evaluation of the CAR. So, we have no problem yet with single name space Common Lisp.
Thank you for your interest on my reports.
Masayuki Ida
∂05-Feb-87 0134 willc%tekchips.tek.com@RELAY.CS.NET Re: Binding, etc.
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Feb 87 01:34:27 PST
Received: from tektronix.tek.com by csnet-relay.csnet id ao00832;
5 Feb 87 0:54 EST
Received: by tektronix.TEK.COM (5.31/6.19)
id AA05928; Wed, 4 Feb 87 17:55:40 PST
Received: by tekchips.TEK (5.31/6.16)
id AA14188; Wed, 4 Feb 87 17:54:27 PST
Message-Id: <8702050154.AA14188@tekchips.TEK>
To: COMMON-LISP@SU-AI.ARPA
Subject: Re: Binding, etc.
Date: 04 Feb 87 17:54:26 PST (Wed)
From: willc%tekchips.tek.com@RELAY.CS.NET
In article <10248@tektronix.TEK.COM> wilensky%larch.Berkeley.EDU@UCBVAX.BERKELEY.EDU (Robert Wilensky) writes:
>
>Some time ago I sent around a flame on the issue of the ``binding''
>terminology in Common LISP. My contention is that the whole notion of
>binding as used in the LISP community is not particularly coherent.
This is certainly true of the Common Lisp community. On the other hand,
the notion of binding used in the Revised↑3 Report on the Algorithmic
Language Scheme (1986) is quite coherent.
I would warn that the word "variable" is used in even more different senses
and is even more confusing than the word "binding". For example, the 1986
Scheme report uses the word "variable" to mean an identifier that denotes a
location, while Wilensky uses the word "variable" to mean a location itself.
It would also be good to distinguish between identifiers (which occur in
code and are typically used as variables in the Scheme sense) and symbols
(which occur in data structures and are typically used as enumerated values).
Many dialects of Lisp require that identifiers be represented internally as
symbols, but Scheme and most other programming languages do not.
Peace, William Clinger
Tektronix, Inc.
∂05-Feb-87 0819 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Common Lisp LOOP macro
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 08:19:43 PST
Date: Thu, 5 Feb 1987 11:18 EST
Message-ID: <STEVER.12276643868.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp@SAIL.STANFORD.EDU
Subject: Common Lisp LOOP macro
A few months back, someone mentioned a public domain Common Lisp
version of the (Maclisp/Zetalisp) LOOP macro. Does anyone
know where I can get a hold of that?
- Stever
∂05-Feb-87 0955 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Binding terminology
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 09:53:14 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47378; Thu 5-Feb-87 11:39:35 EST
Date: Thu, 5 Feb 87 11:36 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Binding terminology
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Pavel.pa@Xerox.COM,
Miller.PA@XEROX.COM
cc: Common-Lisp@sail.stanford.edu
In-Reply-To: <870204221242.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870205113629.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 4 Feb 87 22:12 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I don't think you understood what I said. What I said has nothing to do
with implementation.
Right. I just went through this argument on some other mailing list.
It has nothing to do with deep/shallow, which is purely an internal
implementation issue. We're talking about language semantics.
Consider the following program fragment:
(defvar *a*)
(defun foo (x)
(+ x *a*))
(defun bar-1 ()
(let ((*a* 5))
(x 4)))
(defun bar-2 ()
(let ((*a* 9))
(x 3)))
Now, consider the following question: "The body of x is a function-call
form that adds two variables. The first variable is a lexical variable
named x. Which variable is the second variable referenced by x?"
I believe that this question has a single, clear answer. *x* always
refers to one particular variable, and it's that variable.
The alternative view is to say that there isn't any answer to the
question; it depends on who is calling foo, and what the environment is
at the time, and stuff like that. Simply looking at foo does not tell
you what variable foo is talking about. In order to explain Lisp this
way, you need to introduce some kind of new concept called an
"identifier" or something, that is separate from the concept of a
"variable", and say that the association from a given identifier to a
given variable depends, in some cases, on what conditions prevail at
runtime. This mapping from identifiers to variables cannot always be
determined lexically, but must be determined dynamically.
Such a philosophy seems pointless. Having gotten "rid" of dyanamic
binding of variables to values, you have replaced it with a new concept
of identifiers, and a dynamic binding of "identifiers" to "variables".
No complexity has been removed, and a new fundmental concept has been
added, resulting in a new gain in complexity for no benefit.
∂05-Feb-87 1008 DLA@DIAMOND.S4CC.Symbolics.COM REMF and REMPROP
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 10:05:59 PST
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53127; Wed 4-Feb-87 20:03:00 EST
Date: Wed, 4 Feb 87 20:02 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: REMF and REMPROP
To: Fahlman@C.CS.CMU.EDU
cc: common-lisp@SAIL.STANFORD.EDU, DCP@QUABBIN.SCRC.Symbolics.COM,
DLA@DIAMOND.S4CC.Symbolics.COM
In-Reply-To: <FAHLMAN.12276384296.BABYL@C.CS.CMU.EDU>,
<FAHLMAN.12276430880.BABYL@C.CS.CMU.EDU>
Message-ID: <870204200257.6.DLA@LIMPKIN.S4CC.Symbolics.COM>
Date: Wed, 4 Feb 1987 11:33 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I guess this is yet another thing that needs to be clarified. Here are
a couple of opinions that may be of use in the meantime:
First, it is in the nature of property lists that they get destructively
modified, and it is a remarkably bad idea to write code of the sort you
describe that shares this top-level list structure. Anyone who writes
code that does this should change the code to something sensible and not
quibble about what is legal.
We agree here.
On the other hand, it seems to me that it violates the (implicit)
contract of a destructive operation like REMPROP to take the excised
piece of list and chop it up into little pieces or to re-use the list
cells that it snipped out. The fact that some built-in operation makes
a destructive change does not necessarily give this operation the right,
or the necessary global perspective, to decide what is garbage and what
is not. Sharing is possible in Common Lisp, and it is the garbage
collector's job to decide what cons cells can safely be recycled.
Destructive operations should do what they are documented to do, and no
more.
If this is the case, then they should be documented to do something.
Consider: I can think of two plausible implementations of REMPROP which
"only do their contract". The first one is the zetalisp version which
requires that the top-level list be spliced in a specific fashion. The
second would be a function which pulled all the elements of the plist
after the removed property pair forward, and set the CDR of the tail
NIL. I will argue that both of these functions "do what they are
documented to do, and no more". However, programs which share property
lists would behave differently in the two hypothetical implementations.
So my question is, if this is allowed, why can't I wreak my own havoc
with the spare conses, which has the same effect?
∂05-Feb-87 1008 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM REMF and REMPROP
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 10:05:58 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 52901; Wed 4-Feb-87 12:10:27 EST
Date: Wed, 4 Feb 87 12:13 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: REMF and REMPROP
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>,
DLA@QUABBIN.SCRC.Symbolics.COM, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12276384296.BABYL@C.CS.CMU.EDU>
Message-ID: <870204121313.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Wed, 4 Feb 1987 11:33 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
On the other hand, it seems to me that it violates the (implicit)
contract of a destructive operation like REMPROP to take the excised
piece of list and chop it up into little pieces or to re-use the list
cells that it snipped out. The fact that some built-in operation makes
a destructive change does not necessarily give this operation the right,
or the necessary global perspective, to decide what is garbage and what
is not. Sharing is possible in Common Lisp, and it is the garbage
collector's job to decide what cons cells can safely be recycled.
Destructive operations should do what they are documented to do, and no
more.
I can interpret parts of that paragraph two ways. One way (the way I
don't want to) is that REMF can go off and bash the value. That's not
what Andre was suggesting. He was suggesting only the structure that IS
the property list. Here's a more explicit example:
(setq *key* '(a b c)
*value* '(x y z)
*plist* (list :a 'a *key* *value* :c 'c)
*subplist* (cddr *plist*)
*subsubplist* (cdr *subplist*))
What happens by doing (remf *plist* *key*)? Because REMF is destructive
on the PLIST, I think everyone will agree that
*plist* => (:a a :c c)
I think everyone will also agree that
*key* => (a b c)
*value* => (x y z)
because REMF isn't allowed to bash the key or value. The question is:
What are the values of *subplist* and *subsubplist*? Possible answers
include:
*subplist* ((a b c) (x y z) :c c) ;preserve everything
(nil nil :c c) ;drop pointers to the key and value
(nil nil) ;drop pointers and bash structure
(nil) ;ditto, bashing harder
*subsubplist* ((x y z) :c c)
(nil :c c)
(nil)
REMF has not decided what IS garbage, but it has ALLOWED (a b c) and (x
y z) to be garbage if there are no other pointers to them.
∂05-Feb-87 1008 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Re: Rational Infinity
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 10:05:58 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53081; Wed 4-Feb-87 17:32:12 EST
Date: Wed, 4 Feb 87 17:34 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Re: Rational Infinity
To: Richard Fateman <fateman@renoir.Berkeley.EDU>,
DCP@QUABBIN.SCRC.Symbolics.COM, common-lisp@sail.stanford.edu,
jbarnett@NRTC.ARPA
In-Reply-To: <8702041935.AA28650@renoir.Berkeley.EDU>
Message-ID: <870204173457.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Wed, 4 Feb 87 11:35:39 PST
From: fateman@renoir.Berkeley.EDU (Richard Fateman)
there are also complex numbers and complex infinities of both
rational and floating-point forms in CL. These must be dealt with.
The with-rational-trap-enables ... proposal suggests that
trap enabling should have dynamic scope. Do you mean this?
Yes, I do mean for them to have dynamic scope. I'd hate to try to write
a program that has to put one of these around the lexical scope of each
possible division, which may not even be division of ratios. It's like
the scope of *read-base*; it affects how the program runs.
∂05-Feb-87 1058 hplb29a!hplbgw!weeks@hplabs.HP.COM a historical inquiry
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 5 Feb 87 10:52:12 PST
Received: by hplabs.HP.COM ; Thu, 5 Feb 87 10:30:45 pst
Received: from hplbgw (hplbgw) by hplb29a ; Thu, 5 Feb 87 10:31:42 pst
Received: by hplbgw ; Thu, 5 Feb 87 10:30:25 pst
Date: Thu, 5 Feb 87 10:30:25 pst
From: Gregory Weeks <hplb29a!hplbgw!weeks@hplabs.HP.COM>
Message-Id: <8702051830.AA06435@hplbgw>
To: common-lisp@su-ai.ARPA
Subject: a historical inquiry
Cc: hplbgw!weeks@hplabs.HP.COM
Could someone tell me what motivated people to include special variables in
Common Lisp? Was there any dispute at the time? I'm NOT trying to start a
discussion; I'm just curious.
∂05-Feb-87 1108 FAHLMAN@C.CS.CMU.EDU REMF and REMPROP
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 11:05:17 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 5 Feb 87 14:06:13-EST
Date: Thu, 5 Feb 1987 14:06 EST
Message-ID: <FAHLMAN.12276674308.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: REMF and REMPROP
In-reply-to: Msg of 4 Feb 1987 20:02-EST from David L. Andre <DLA at DIAMOND.S4CC.Symbolics.COM>
In reply to: David L. Andre <DLA at DIAMOND.S4CC.Symbolics.COM>
Destructive operations should do what they are documented to do, and no
more.
If this is the case, then they should be documented to do something.
Consider: I can think of two plausible implementations of REMPROP which
"only do their contract". The first one is the zetalisp version which
requires that the top-level list be spliced in a specific fashion. The
second would be a function which pulled all the elements of the plist
after the removed property pair forward, and set the CDR of the tail
NIL. I will argue that both of these functions "do what they are
documented to do, and no more". However, programs which share property
lists would behave differently in the two hypothetical implementations.
So my question is, if this is allowed, why can't I wreak my own havoc
with the spare conses, which has the same effect?
In my view, it isn't allowed, or at least it shouldn't be done this way.
If you want to think up bizarre ways of implementing things, argue that
these are legal because the book doesn't explicitly forbid them, and
then use these things to justify "wreaking havoc" because the book
doesn't forbid that either, then I guess your position is defensible, at
least. I can't point to any particular sentence in CLtL that says that
what you propose to do is illegal. I just think that it violates the
reasonable expectations of the users; most will assume that two backbone
cells are snipped from the list without any further reordering unless
the manual warns them that something more complex might be going on.
It's good design philosophy for an implementor not to exploit loopholes
in the spec in ways that will screw users. As I said before, in this
particular case, any user who gets in trouble was skating too close to
the edge anyway, but I still don't think you should set traps for the
unwary.
-- Scott
∂05-Feb-87 1205 DLW@ALDERAAN.SCRC.Symbolics.COM a historical inquiry
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 11:59:46 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47497; Thu 5-Feb-87 14:58:04 EST
Date: Thu, 5 Feb 87 14:54 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: a historical inquiry
To: hplb29a!hplbgw!weeks@hplabs.HP.COM, common-lisp@SU-AI.ARPA
cc: hplbgw!weeks@hplabs.HP.COM
In-Reply-To: <8702051830.AA06435@hplbgw>
Message-ID: <870205145450.1.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 5 Feb 87 10:30:25 pst
From: Gregory Weeks <hplb29a!hplbgw!weeks@hplabs.HP.COM>
Could someone tell me what motivated people to include special variables in
Common Lisp?
(1) They're tremendously useful. Nearly every major Lisp software
system I've ever used has used them to great advantage, and would suffer
significantly if they were not available. Of course, the vast majority
of variables are lexical, but the few dynamic variables play important
roles.
(2) It was considered important to allow existing software to be
converted to Common Lisp in a relatively straightforward fashion.
Was there any dispute at the time?
No. (In fact, at the time there was some debate about full lexical
scoping with upward and downward funargs; some people were dubious about
implementation issues.)
∂05-Feb-87 1223 FAHLMAN@C.CS.CMU.EDU a historical inquiry
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 12:14:12 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 5 Feb 87 15:14:10-EST
Date: Thu, 5 Feb 1987 15:14 EST
Message-ID: <FAHLMAN.12276686673.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Gregory Weeks <hplb29a!hplbgw!weeks@HPLABS.HP.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: a historical inquiry
In-reply-to: Msg of 5 Feb 1987 13:30-EST from Gregory Weeks <hplb29a!hplbgw!weeks at hplabs.HP.COM>
Special values (or dynamic scoping, if you prefer) are very useful in
some situations. There was never any suggestion that we eliminate them
completely, and I don't think there would be today. All of the
discussion was about whether Lexical or dynamic scoping should be the
default.
-- Scott
∂05-Feb-87 1237 Margolin.VS3@BCO-MULTICS.ARPA REMF and REMPROP
Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 5 Feb 87 12:34:43 PST
Date: Thu, 5 Feb 87 15:33 EST
From: Barry Margolin <Margolin@BCO-MULTICS.ARPA>
Subject: REMF and REMPROP
To: common-lisp@SU-AI.ARPA
Message-ID: <870205203355.967711@BCO-MULTICS.ARPA>
I don't think it is legal for REMPROP to be equivalent to (SETF (GET
SYMBOL PROP) NIL), which seemed to be one of the possibilities mentioned
in the original mail. Doesn't GET return a second value indicating
whether the indicator was found or not, so that a value of NIL can be
distinguished from a NIL used to indicate failer? Or is it only the
hashing functions that do this?
barmar
∂05-Feb-87 1420 gls@think.com a historical inquiry
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Feb 87 14:15:43 PST
Received: from Godot.Think.COM by zarathustra.think.com; Thu, 5 Feb 87 17:14:32 EST
Received: from boethius by Godot.Think.COM via CHAOS; Thu, 5 Feb 87 17:14:17 EST
Date: Thu, 5 Feb 87 17:15 EST
From: Guy Steele <gls@think.com>
Subject: a historical inquiry
To: hplb29a!hplbgw!weeks@hplabs.hp.com, common-lisp@sail.stanford.edu
Cc: hplbgw!weeks@hplabs.hp.com, gls@Think.COM
In-Reply-To: <8702051830.AA06435@hplbgw>
Message-Id: <870205171543.3.GLS@BOETHIUS.THINK.COM>
Date: Thu, 5 Feb 87 10:30:25 pst
From: Gregory Weeks <hplb29a!hplbgw!weeks@hplabs.hp.com>
Could someone tell me what motivated people to include special variables in
Common Lisp? Was there any dispute at the time? I'm NOT trying to start a
discussion; I'm just curious.
Given the state of Lisp practice at the time, better yet you should
ask "What motivated people to include any kind of variable OTHER
than special variables?" (Recall that SCHEME was not nearly as
popular then as now, and nearly every other Lisp used only dynamic
binding in the interpreter and dynamic and local binding in
compiled code.)
--Guy
∂05-Feb-87 1551 hoey@nrl-aic REMF and REMPROP
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 5 Feb 87 15:30:03 PST
Date: 5 Feb 1987 17:50:05 EST (Thu)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: REMF and REMPROP
To: common-lisp@su-ai.ARPA
Message-Id: <539560403/hoey@nrl-aic>
I can't believe that shredding discarded pieces of plists to help
garbage collection could serve much of a useful purpose. But it might
be very useful in CDR-coded implementations to do REMF by copying the
last pair of the property list into the newly-vacated position, and
even to secretly remember the empty spaces this leaves after the end of
the list for future use by (SETF (GETF...)). This would mean that
structure once shared with the plist backbone might be changed fairly
surprisingly by REMF or (SETF (GETF...)).
I think users who rely on the assumption that system functions are
implemented in the most obvious way are in too much trouble for a
warning about REMF to help them. There has to be a distinction made
between ``exploiting loopholes'' in the standard and taking advantage
of the standard's deliberate flexibility. The implied contract of the
property list functions has to be spelled out, something like:
GETF does not structure. (REMF <place> ...) and
(SETF (GETF <place> ...)) modify only <place> and its top-level
list structure.
It's unfortunate we can't get along without the first sentence,
considering what a win it can be to dynamically order property lists.
Dan
∂05-Feb-87 1633 hilfingr%tully.Berkeley.EDU@BERKELEY.EDU Re: Binding terminology
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 16:29:20 PST
Received: by ucbvax.Berkeley.EDU (5.53/1.20)
id AA18428; Thu, 5 Feb 87 16:24:52 PST
Received: by tully (1.1/5.17)
id AA03116; Thu, 5 Feb 87 16:24:42 PST
Date: Thu, 5 Feb 87 16:24:42 PST
From: hilfingr%tully.Berkeley.EDU@BERKELEY.EDU (Paul Hilfinger)
Message-Id: <8702060024.AA03116@tully>
To: DLW@alderaan.scrc.symbolics.com, Miller.PA@xerox.com,
Moon@stony-brook.scrc.symbolics.com, Pavel.pa@xerox.com
Subject: Re: Binding terminology
Cc: Common-Lisp@sail.stanford.edu
Daniel Weinreb writes:
"Now, consider the following question: `The body of x is a function-call
form that adds two variables. The first variable is a lexical variable
named x. Which variable is the second variable referenced by x?"
I believe that this question has a single, clear answer. [*a*] always
refers to one particular variable, and it's that variable.
The alternative view is to say that ...
it depends on who is calling foo, and what the environment is
at the time.... Simply looking at foo does not tell
you what variable foo is talking about. In order to explain Lisp this
way, you need to introduce some kind of new concept called an
"identifier" ... that is separate from the concept of a
"variable", and say that the association from a given identifier to a
given variable depends, in some cases, on what conditions prevail at
runtime....
Such a philosophy seems pointless. Having gotten "rid" of dyanamic
binding of variables to values, you have replaced it with a new concept
of identifiers, and a dynamic binding of "identifiers" to "variables".
No complexity has been removed, and a new fundmental concept has been
added, resulting in a new gain in complexity for no benefit.
-----------
This is a really good try at standing the situation on its head, but it
doesn't quite make it.
(1) Having been told that *a* always means the same variable (and having
then discovered what that really means) the questioner's response
would then be, "Oh, I meant to ask something else, then: which of
the values-that-have-been-assigned-to-*a*-in-such-a-way-that-they-are-
currently-available-or-might-be-restored-later does *a* have?" (The
long, hyphenated construct is used to avoid introducing a new concept,
which some call "binding", since this description of Lisp is not
supposed to require introducing a new concept beyond "variable.")
To put this all less cutely: TANSTAAFL; if there is only one variable,
there have to be several of something else. The number of concepts
is NOT reduced by there being just one variable.
(2) The "identifier" argument is a bit weak, since Lisp already has a
concept of "symbol," which will serve for all but pedants.
(3) The argument concerning future extensions for parallelism is, in
my mind, a good one. If the same symbol, when not lexically bound
always refers to the same "variable" and if the properties of that
variable (e.g., its value) do not depend on the environment (but
instead are changed by certain program constructs, including setq
and let), then you'll have a little difficulty explaining how the
same dynamically bound variable (i.e., referenced by the same
symbol) can have two different values when simultaneously read by
two concurrent processes (and, yes, you certainly DO want to be
able to have two concurrent processes simultaneously providing two
lambda bindings for the same--in CLtL and Weinreb's
terminology--variable.)
∂05-Feb-87 1700 DLW@ALDERAAN.SCRC.Symbolics.COM Re: Binding terminology
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 5 Feb 87 17:00:10 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47695; Thu 5-Feb-87 19:58:13 EST
Date: Thu, 5 Feb 87 19:55 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Binding terminology
To: hilfingr%tully.Berkeley.EDU@BERKELEY.EDU
cc: Common-Lisp@sail.stanford.edu
In-Reply-To: <8702060024.AA03116@tully>
Message-ID: <870205195512.9.DLW@CHICOPEE.SCRC.Symbolics.COM>
OK, I buy that. I now revise my statement as follows. Having gotten
rid of the mechanism for binding variables to values, you have simply
introduced a similar mechanism for binding symbols to variables.
Nothing has been gained. Instead of worrying about the current value of
the variable, now I must worry about the current variable of the symbol.
So while there's no gain in complexity, there's no reduction in
complexity either.
Parallelism makes the same demand no matter which of the two models you
use. Either you have to explain that the value of a variable depends on
what process asks the question, or you have to explain why the variable
of the symbol depends on which process asks the question. There's
still a mapping going on, and it still has to be process-dependent.
∂05-Feb-87 1814 coffee@aerospace.aero.org Re: REMF and REMPROP
Received: from AEROSPACE.ARPA by SAIL.STANFORD.EDU with TCP; 5 Feb 87 18:13:00 PST
Received: by aerospace.aero.org (5.51/6.0.GT)
id AA20215; Thu, 5 Feb 87 16:36:57 PST
Posted-Date: Thu, 05 Feb 87 16:36:51 -0800
Message-Id: <8702060036.AA20215@aerospace.aero.org>
To: Barry Margolin <Margolin@bco-multics.ARPA>
Cc: common-lisp@sail.stanford.edu
Subject: Re: REMF and REMPROP
In-Reply-To: Your message of Thu, 5 Feb 87 15:33 EST.
<870205203355.967711@BCO-MULTICS.ARPA>
Date: Thu, 05 Feb 87 16:36:51 -0800
From: coffee@aerospace.aero.org
From Steele, p.165: "Note that there is no way to distinguish an absent
property from one whose value is <default>." The <default> argument is
optional and defaults in turn to nil, so get on an absent property is
normally identical in value to get on a property with explicit value nil.
Winston & Horn, p.97, shows (setf (get <sym> <prop>) nil) as equivalent
to remprop "as far as get is concerned...although it is better programming
practice to use remprop."
Cheers, Pc↑2
∂05-Feb-87 2154 @BCO-MULTICS.ARPA:Margolin.Multics@HIS-PHOENIX-MULTICS.ARPA Re: REMF and REMPROP
Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 5 Feb 87 21:52:05 PST
Received: FROM HIS-PHOENIX-MULTICS.ARPA BY BCO-MULTICS.ARPA WITH dial; 06 FEB 1987 00:37:40 EST
Sender: Barry Margolin <Margolin@HIS-PHOENIX-MULTICS.ARPA>
Date: Thu, 5 Feb 87 22:31 MST
From: Barry Margolin <Margolin@BCO-MULTICS.ARPA>
Subject: Re: REMF and REMPROP
To: coffee@AEROSPACE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message of 5 Feb 87 17:36 MST from "coffee at AEROSPACE.AERO.ORG"
Message-ID: <870206053142.271474@HIS-PHOENIX-MULTICS.ARPA>
Date: 5 February 1987 17:36 mst
From: coffee at AEROSPACE.AERO.ORG
Subject: Re: REMF and REMPROP
From Steele, p.165: "Note that there is no way to distinguish an absent
property from one whose value is <default>." The <default> argument is
optional and defaults in turn to nil, so get on an absent property is
normally identical in value to get on a property with explicit value nil.
Winston & Horn, p.97, shows (setf (get <sym> <prop>) nil) as equivalent
to remprop "as far as get is concerned...although it is better programming
practice to use remprop."
Cheers, Pc↑2
Since the caller of GET can specify the default value, it would not be
valid for REMPROP to set it to NIL. Consider the difference between
(REMPROP 'foo :bar)
(GET 'foo :bar 'my-default) => my-default
and
(SETF (GET 'foo :bar) NIL)
(GET 'foo :bar 'my-default) => NIL
So, while the caller of GET cannot distinguish a missing value from the
default value, GET must be able to detect that a property is missing.
By the way, here is a function that reliably provides the two-value
interface I described:
(defun my-get (symbol indicator &aux (default (ncons nil)))
(let ((value (get symbol indicator default)))
(if (eq value default)
(values nil nil)
(values value t))))
barmar
∂05-Feb-87 2241 edsel!bhopal!jonl@navajo.stanford.edu Rational Infinity
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 22:40:53 PST
Received: by navajo.stanford.edu; Thu, 5 Feb 87 22:38:30 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA17939; Thu, 5 Feb 87 22:29:19 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA03285; Thu, 5 Feb 87 22:33:00 PST
Date: Thu, 5 Feb 87 22:33:00 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8702060633.AA03285@bhopal.edsel.com>
To: navajo!Cassels%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: Robert A. Cassels's message of Wed, 4 Feb 87 09:27 EST
Subject: Rational Infinity
Re: The existence of infinite rational objects and how they come about are
two separate issues. . . .
Very good point.
Re: . . . One of the reasons that
rational infinities aren't in Common Lisp yet is that there is some
debate about whether rational infinity is affine (signed) or projective
(unsigned).
Although Common Lisp doesn't require IEEE floating-point capability, I
think most people would agree that it's a reasonable goal to reach for.
For compability with the infinities available there, one would like to
have both +1/0 and -1/0 (I presume we can agree on a canonical form
for a rational infinity, that its denominator should be 0 and its
numerator's magnitude should be 1 ?)
-- JonL --
∂05-Feb-87 2308 edsel!bhopal!jonl@navajo.stanford.edu Re: Binding terminology
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 5 Feb 87 23:05:23 PST
Received: by navajo.stanford.edu; Thu, 5 Feb 87 23:02:44 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA18019; Thu, 5 Feb 87 22:38:38 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA03309; Thu, 5 Feb 87 22:42:22 PST
Date: Thu, 5 Feb 87 22:42:22 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8702060642.AA03309@bhopal.edsel.com>
To: navajo!DLW%ALDERAAN.SCRC.Symbolics.COM@navajo.stanford.edu,
navajo!hilfingr%tully.Berkeley.EDU@navajo.stanford.edu
Cc: navajo!Common-Lisp%sail@navajo.stanford.edu
Subject: Re: Binding terminology
There is a sense in which it is easy to confuse the capabilities of the
extant "shallow bound" implementations with the semantics implicit and
explicit in Lisp 1.5. MIT Professor Joel Moses wrote a paper in 1970
entitled "The Function of FUNCTION in Lisp" in which he exposed some of
the mis-conceptions then prevalent. The most common one was that "deep
binding" was Lisp 1.5, and "shallow binding" wasn't; in fact, neither of
the then-extant models was correct in the Lisp 1.5 sense. The problem
lay in the ephemeral nature of the the objects used to hold bindings,
rather than in the deep-versus-shallow question.
One may over-generalize this criticism to say that there is no functional
difference between deep and shallow binding, but only performance
consequences. This generalization is incorrect, as the subsequent
discussion will show.
The terminology in use during the mid-1970's was that the name/value
pair in the environment "alist" (Lisp 1.5 model) was a "binding" rather
than the creation of a new variable such as Wilensky suggests. It's
not entirely confusing to think of the entries in the alist as "value
cells". So the alist model of binding permits you to think of having
simultaneously many value cells, whereas the shallow-binding model
clearly has only one "value cell". The difference is more apparent when
you talk about constructing environment objects; in the Lisp 1.5 model,
you are pointing at a (shared) alist, whereas the shallow-bound models
usually didn't implement this very well, if at all.
Not long after Moses' paper appeared, Dan Bobrow at BBN (and others also)
developed the "spaghetti stack" model, which was supposed to have exactly
the same semantics as the Lisp 1.5 model; indeed, most "spaghetti"
implementations seem to weave the alist of Lisp 1.5 into subparts of the
stack-frames allocated to run the program. The "deep bound"
implementations which I am familiar with today are all variants of the
"spaghetti stack" model; so I wouldn't be surprised to see people
confusing "deep binding" questions with "environment retention" questions.
It is still the case that the extant "shallow bound" models are not as
rich at approximating the Lisp 1.5 model. In particlar, there is no
way for them to create a "full" funarg -- that is, one that closes over
the entire dynamic environment at the time of creation. When the Lisp
Machine project first started, I remember Greenblatt coming up with the
limited closure idea, whereby the user had to state explicitly which
dynamic variables would be "closed over". (If someone else thinks they
invented that idea, then maybe they did -- I just remember RG stating it).
It was widely recognized then that this did not solve the so-called
FUNARG problem; but it was a somewhat useful device. [Considering
how well entrenched the use of dynamic variables has been, I was
moderately surprised that the Common Lisp community could agree as
early as 1983 to flush dynamic closuers of any kind; but Scheme's
influence showed how useful lexical-only closuers could be, and
they didn't require a "spaghetti stack" for implementation.]
In the late 1970's or early 1980's, Henry Baker wrote a paper dealing
with shallow binding in MacLisp and "re-rooting", in which he showed
how you could still model Lisp variables by storing their "current"
value in a "shallow" cell, but have the same semantics as the
"spaghetti-stack" implementations. The important observation which
he made was that there is an explicit, user-visible construct which
must be invoked to change environments; at the time of switching
contexts (read: environments), the processor could go around "patching
up" all the relevant "shallow" value cells.
However, neither the Baker idea nor stack-group switching will work
for parallel processors. There is no synchronizing event occuring
between two processors, running in two different "environments", which
would initiate the re-rooting of the shallow cells. The obvious solution
is for each environment to have it's own unique "value cell" for
the dynamically-bound variables; this is what deep binding accomplishes.
I have heard of an idea about pairing a "process id" cell along with
a shallow value cell; the idea being that each process (presumably
being run by an independent processor) would validate the "process id"
before using the shallow cell; and of course there would be appropriate
locks/semaphores to cover the critical periods of update. But I don't
believe this works any better than the optimizations currently in use
by the deep-binding implementations.
-- JonL --
∂06-Feb-87 0659 DLA@DIAMOND.S4CC.Symbolics.COM REMF and REMPROP
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 6 Feb 87 06:58:43 PST
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 53716; Fri 6-Feb-87 09:53:24 EST
Date: Fri, 6 Feb 87 09:53 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Reply-To: DLA@STONY-BROOK.SCRC.Symbolics.COM
Subject: REMF and REMPROP
To: Margolin@BCO-MULTICS.ARPA, coffee@aerospace.aero.org
cc: common-lisp@SU-AI.ARPA, DLA@DIAMOND.S4CC.Symbolics.COM
In-Reply-To: <870205203355.967711@BCO-MULTICS.ARPA>,
<8702060036.AA20215@aerospace.aero.org>,
<870206053142.271474@HIS-PHOENIX-MULTICS.ARPA>
Message-ID: <870206095318.9.DLA@LIMPKIN.S4CC.Symbolics.COM>
Sigh. Since only Fahlman and Masinter seem to have understood what I
said, I'm going to explain it one more time, rather than sending
individual explanations to people who didn't understand. I am not
advocating changing REMPROP to be equivalent to (SETF (GET SYMBOP PROP) NIL).
I am advocating changing the function as follows, in Symbolics Common Lisp:
Before: (defun old-remprop (symbol indicator)
(let* ((ppl (locf (symbol-plist symbol)))
(pl (location-contents ppl)))
(loop
(when (endp pl) (return nil))
(when (eq (pop pl) indicator)
(setf (location-contents ppl) (cdr pl))
(return (return t)))
(psetf ppl pl pl (cdr pl)))))
After: (defun new-remprop (symbol indicator)
(let* ((ppl (locf (symbol-plist symbol)))
(pl (location-contents ppl)))
(loop
(when (endp pl) (return nil))
(when (eq (pop pl) indicator)
(setf (location-contents ppl) (cdr pl))
*** Change --> (setf (car pl) nil)
(return (return t)))
(psetf ppl pl pl (cdr pl)))))
(For those of you unfamiliar with Symbolics Common Lisp, LOCF returns a
"locative cell" to the place referenced, which can be then set or
referenced using LOCATION-CONTENTS. LOCATION-CONTENTS = CDR.)
If the symbol-plist is the only pointer to the property list, then the
behavior of the new-remprop is NO DIFFERENT from old-remprop. The
change merely allows the garbage collector to reclaim the removed
property in the case where the plist is not immediately reclaimed. I
view this as an important case because many times programmers use
REMPROP to "remove pointers to structures no longer referenced".
I am writing a formal proposal to CL-Cleanup, and will try to represent
the views others have expressed as best I can.
∂06-Feb-87 0706 DLW@ALDERAAN.SCRC.Symbolics.COM REMF and REMPROP
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 6 Feb 87 07:05:53 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47843; Fri 6-Feb-87 10:04:15 EST
Date: Fri, 6 Feb 87 10:01 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: REMF and REMPROP
To: Fahlman@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12276674308.BABYL@C.CS.CMU.EDU>
Message-ID: <870206100113.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Thu, 5 Feb 1987 14:06 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
It's good design philosophy for an implementor not to exploit loopholes
in the spec in ways that will screw users. As I said before, in this
particular case, any user who gets in trouble was skating too close to
the edge anyway, but I still don't think you should set traps for the
unwary.
That's a strange idea of "good design philosophy". It seems to me that
we are trying to write a specification for a portable common subset
here. It seems to me that the specification should say one of two
things:
[1] All implementations of Common Lisp are REQUIRED to obey the
following contract. Any implementation that does not follow the
contract is in VIOLATION of the definition. Any program written in
Common Lisp is FREE to depend on and take advantage of the contract.
[2] The following aspect of the operation of this function is NOT
REQUIRED. Implementations might choose to have this aspect, or not have
this aspect, or work a different way, because this aspect is NOT part of
the contract. Any program written in Common Lisp is FORBIDDEN to depend
on this aspect, or else it is not portable.
You seem to feel there is a third class:
[3] The following aspect of the operation of this function, while NOT
REQUIRED by the Common Lisp spec, because it doesn't say anything about
the aspect one way or another, is REQUIRED anyway because Fahlman deems
it to be a "loophole". Any program in Common Lisp is FREE to depend on
it, except that they might not run in implementations where nobody was
quite sure which things were considered "loopholes" or not.
In other words, either we should SPECIFY the behavior of REMF and
friends EXPLICITLY as part of the Common Lisp definition, or we should
admit that it is UNSPECIFIED, and implementations can do what they want,
and users had better be aware of it. I don't see how there can be any
middle ground.
In other words, we should be quite explicit about what's required and
what's not required, and make sure it's stated clearly in the spec.
Here, it seems to me that we are discussing a tradeoff. We can (1) make
the behavior more specifically defined in terms of the nitty-gritty that
it does; Pro: users can depend on that nitty-gritty and still have their
programs be portable; Con: implementations are restricted to work that
way, even if it degrades performance; or (2) make the behavior be
defined more abstractly; Pro: the system has more latitude to implement
things more efficiently; Con: the users can only use the function for
its abstract purpose, and not take advantage of the way it works inside.
Either we decide that the users are too damned close to the ice, they
should not be doing those things, and (2) is the way to go, or we decide
that this is a trap for the unwary, users have to or want to depend on
these internals, and (1) is the way to go. I don't see how we can have
it both ways.
∂06-Feb-87 0739 FAHLMAN@C.CS.CMU.EDU REMF and REMPROP
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Feb 87 07:39:38 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 6 Feb 87 10:36:35-EST
Date: Fri, 6 Feb 1987 10:36 EST
Message-ID: <FAHLMAN.12276898296.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: REMF and REMPROP
In-reply-to: Msg of 6 Feb 1987 10:01-EST from Daniel L. Weinreb <DLW at ALDERAAN.SCRC.Symbolics.COM>
In response to: Daniel L. Weinreb <DLW at ALDERAAN.SCRC.Symbolics.COM>
In other words, either we should SPECIFY the behavior of REMF and
friends EXPLICITLY as part of the Common Lisp definition, or we should
admit that it is UNSPECIFIED, and implementations can do what they want,
and users had better be aware of it. I don't see how there can be any
middle ground.
In other words, we should be quite explicit about what's required and
what's not required, and make sure it's stated clearly in the spec.
I've got no argument with this. As these issues come up, the best thing
to do is to get each one officially clarified, one way or the other. But
adopting official clarifications is a slow process -- absurdly slow,
unfortunately -- and there will always be some issues that we have not
yet clarified. I was attempting to give my own view on a reasonable
philosophy for handling these things prior to an official clarification:
In cases where it is obvious that most users will have a certain model
of how an operation is going to be implemented, it is best not to go
against that model. If there is tremendous advantage to be gained by
implementing something in an unusual way that has surprising
consequences, then it may be worth doing, but in this case the
documentation for that implementation should make a big point of
explaining what is going on (and still some users will miss that and be
screwed, because many of them tend to look only in CLtL).
I really don't care what you do in this case, since so few people will
be affected, nor do I care which way the issue gets decided when we get
around to deciding it. The only reason I responded is that I thought I
saw an explicit argument that it is OK to do this very strange thing
because the manual does not explicitly forbid it, and that seemed like a
dangerous precedent to me.
-- Scott
∂06-Feb-87 1041 DLW@ALDERAAN.SCRC.Symbolics.COM REMF and REMPROP
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 6 Feb 87 10:37:40 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 47957; Fri 6-Feb-87 13:35:17 EST
Date: Fri, 6 Feb 87 13:32 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: REMF and REMPROP
To: Fahlman@C.CS.CMU.EDU, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12276898296.BABYL@C.CS.CMU.EDU>
Message-ID: <870206133214.7.DLW@CHICOPEE.SCRC.Symbolics.COM>
Date: Fri, 6 Feb 1987 10:36 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I was attempting to give my own view on a reasonable
philosophy for handling these things prior to an official clarification:
Oh, I see. OK.
In cases where it is obvious that most users will have a certain model
of how an operation is going to be implemented, it is best not to go
against that model.
OK, I agree with this. I think the only question is whether it's so
obvious what users are modelling or expecting. It's certainly hard to
come up with a definitive way of resolving that.
∂06-Feb-87 1240 Masinter.pa@Xerox.COM rational infinity
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Feb 87 12:37:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 FEB 87 12:02:18 PST
Date: 6 Feb 87 12:03 PST
From: Masinter.pa@Xerox.COM
Subject: rational infinity
To: common-lisp@sail.stanford.edu
Message-ID: <870206-120218-3664@Xerox>
An alternative to JonL's proposal (which encodes rational infinities as
1/0 and -1/0) would be to put the infninity(ies) in a separate class,
under number, but not part of rational or ratio or integer.
I think this is better than defining infinity using 1/0 or any other
encoding because:
a) CLtL alludes to such a possibility.
b) it is reasonable to want to define an operation as working on, say,
integers including +infinity and -infinity, but not arbitrary other
ratios. That is, the infinities are more an extension of the integer
type than the ratio type.
c) it doesn't require modification of definitions which are *not* valid
for infinity. For example, you might want to leave +, -, * and /
undefined for infinity, but define > >= = /= < <=.
d) adding signed infinity in this way doesn't preclude adding a
projective unsigned infinity.
I claim that the handling of IEEE floating point infinities was a good
design for programming languages where variables must be type declared,
and that one couldn't have a variable (binding? oops, wrong discussion)
which at various times contained floating point numbers and at other
times contained NANs. A Lisp embedding of IEEE floating-point which made
NaNs a separate class (type) would have the advantage of being able to
more simply defining (or not defining) behavior of operations on them.
∂06-Feb-87 1359 coffee@aerospace.aero.org Re: REMF and REMPROP
Received: from AEROSPACE.ARPA by SAIL.STANFORD.EDU with TCP; 6 Feb 87 13:46:58 PST
Received: by aerospace.aero.org (5.51/6.0.GT)
id AA05166; Fri, 6 Feb 87 12:03:54 PST
Posted-Date: Fri, 06 Feb 87 12:03:50 -0800
Message-Id: <8702062003.AA05166@aerospace.aero.org>
To: common-lisp@sail.stanford.edu
Subject: Re: REMF and REMPROP
In-Reply-To: Your message of 06 Feb 87 0659 PST.
<8702061737.AA00893@aerospace.aero.org>
Date: Fri, 06 Feb 87 12:03:50 -0800
From: coffee@aerospace.aero.org
Excuse me, but I was just answering barmar's question -- "Doesn't GET return
two values, the second indicating success or failure?" -- in the negative.
The quote from Winston was somewhat tongue in cheek, illustrating (1) the
extent to which this "Common Lisp" edition is really Common-compatible rather
than really teaching Common _per_se_, (2) the relative rarity of the use of
the optional DEFAULT argument to GET. Personally, I favor minimizing the cost
of property list implementation, leaving people to construct their own
A-List structures where a straightforward implementation of P-Lists doesn't
leave enough flexibility. This is the only "view" of mine that need be
represented, and then only if you care... ;-)
Cheers - Pc↑2
∂06-Feb-87 1958 edsel!bhopal!jonl@navajo.stanford.edu Rational infinities
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Feb 87 19:58:34 PST
Received: by navajo.stanford.edu; Fri, 6 Feb 87 19:57:35 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA00531; Fri, 6 Feb 87 19:41:42 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA05272; Fri, 6 Feb 87 19:47:04 PST
Date: Fri, 6 Feb 87 19:47:04 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8702070347.AA05272@bhopal.edsel.com>
To: navajo!Masinter.pa%Xerox.COM@navajo.stanford.edu
Cc: navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 6 Feb 87 12:03 PST
Subject: Rational infinities
Re: b) it is reasonable to want to define an operation as working on, say,
integers including +infinity and -infinity, but not arbitrary other
ratios. That is, the infinities are more an extension of the integer
type than the ratio type.
Since we currently have
(deftype rational () '(or integer ratio))
then I can't see any benefit to adding a new type that can be compared
with integers, but not with ratios; nor can I see any implementational
benefit to having separate "integer infinities" and "rational infinities".
However, I'm not so much concerned with the implementational details as
with the semantics. For example, If rational infinities answer "false"
to rationalp, then for symmetry shouldn't we require that floating-point
infinities answer "false" to floatp?
Of course, "contagion" rules should apply so that floating-point infinities
can be compared-with/combined-with rational infinities. I think it's ok if
(+ 3/2 <+float-infinity>)
answers "true" to floatp; but I don't want
(/ 10 0)
to give me a floating-point number under any circumstances; and I would
prefer that
(max 3 <+rational-infinity>)
be "rationalp" rather than merely numberp.
Now, the significant question is what to do about complex infinities.
I have some current needs for the two rational infinities -- one of
which is to model floating-point exactly -- but I don't have any ideas
at all about the complex domain. Do you?
-- JonL --
∂06-Feb-87 2006 FAHLMAN@C.CS.CMU.EDU Format for cleanup proposals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Feb 87 20:06:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 6 Feb 87 23:06:12-EST
Date: Fri, 6 Feb 1987 23:06 EST
Message-ID: <FAHLMAN.12277034760.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Format for cleanup proposals
Larry,
I think that this document should just be a proposed format for cleanup
proposals. We should not include a "Report from the cleanup committee".
We'll give a report at the meeting, explaining why things have gone so
slowly and what we hope to do about that, but don't need to send that
out as an X3J13 document right now.
The boilerplate form for proposals should not contain a section
describing the votes of the cleanup committee. I don't think that it is
our job to vote on these things, at least not in the usual sense. It is
our job to formulate coherent, well-debugged proposals for consideration
of X3J13, along with appropriate rationale and our recommendation in
cases where our committee clearly favors one path over another. We may
speak of "voting" on these things, but I see it as a process in which we
are aksing whether anyone on the committee sees any problems, and what
our recommendation should be. Where consensus cannot be reached in our
subcommittee, it should not be a majority-rules situation; rather, we
should send up a set of alternatives, with the arguments for each.
The chairman (and probably the rest of us as well) will want to keep
track of the positions committee members have taken on these issues, but
I submit that the public "proposals" file is the wrong place to do this.
I don't like the proposed classification of proposals into
Clarification, Mistake, Omission, and Enhancement. These are not
disjoint sets. Most of the clarifications result from some omission or
underspecification in CLtL; only a few result from explicit ambiguities.
Classifying something as a mistake would require that the proposer
somehow has access to the intentions of the "authors". I'm not sure
even the authors can remember their intentions reliably in all cases; I
know first-hand that one of them has trouble. You make no provision for
deliberate changes or for non-minor enhancements. I think it is
reasonable to say that we want to avoid those things if possible, but to
adopt a format in which they cannot legitimately be proposed seems like
a mistake (or maybe an omission...).
I would go with Clarification, Change, and Enhancement. It will usually
be obvious from the proposal itself and the rationale whether the issue
is major or minor and whether the proposal is conservative or radical.
Asking the proposers to classify things along these axes doesn't seem
worthwhile.
I also dislike the separate identifiers for issues and proposals.
These are going to get muddled together, and the person making a
proposal will want to describe the issue in his own way.
Finally, I think that the business of assigning canonical identifiers
should be kept as neutral as possible. I would suggest that we allow
the person submitting a proposal to provide some descriptive label
(not-canonical), and the chairman assigns only a number. Yes, some
numbers will get wasted and issues will end up out of order, but anyone
whose checking account provides numbered checks should be used to this
by now.
My revised format proposal is included, so that you can see how it would
look with these changes.
-- Scott
---------------------------------------------------------------------------
Proposal label:
< A short descriptive label provided by the person submitting the
proposal. Something like "Must CDR terminate?" >
Proposal number:
< Assigned by the chairman of the cleanup committee. This will be of the
form A:B:C, where A identifies the issue, B the alternative being
proposed (there may be more than one proposal addressing the same
issue), and C the revision. >
Reference:
< The pages of CLtL which describe the Common Lisp feature being
discussed, if such a reference exists. >
Description of the problem:
< A description of the problem being addressed. Why is the current
situation unclear or unsatisfactory? >
Category:
< One of the following:
CLARIFICATION - proposal to resolve an ambiguitiy or case of
under-specified situation in CLtL, where this ambiguity interferes
with portability of code.
CHANGE - Proposal for an incompatible change to the language.
ENHANCEMENT - Proposal for a compatible extension to the language. >
Description of Proposal:
< Describe as precisely as possible what you are proposing. Ideally,
this should take the form of text that could be dropped into CLtL or
some new specification document. You may propose a set of numbered
alternatives here, rather than one single proposal. >
- - - - - - - - - - - - - - - -
Rationale:
This is the most important part. If more than one alternative proposal
is listed, answer the questions for *all* proposals. Be as brief as
possible.
<a> How does the proposal relate to existing practice? Do some/many/no
Common Lisp implementations already work this way?
<b> What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available?
For pervasive changes, can the conversion be automated?
<c> What are the benfits of adopting the proposal? How serious is the
problem if just left as it is?
<d> For incompatible changes, what is the cost of converting existing
user code? To what extent can the process be automated?
<e> Esthetic critera: How does this proposal affect the simplicty
of the language, ease of learning, etc.
Discussion:
<Any additional arguments, discussions, endorsements, etc. should go here.>
∂07-Feb-87 1952 JAR@AI.AI.MIT.EDU variables
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Feb 87 19:52:04 PST
Date: Sat, 7 Feb 87 22:51:53 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: variables
To: cugini@ICST-ECF.ARPA
cc: common-lisp@SAIL.STANFORD.EDU
In-reply-to: Msg of 4 Feb 87 07:09:00 EST from "CUGINI, JOHN" <cugini at icst-ecf>
Message-ID: <150886.870207.JAR@AI.AI.MIT.EDU>
Date: 4 Feb 87 07:09:00 EST
From: "CUGINI, JOHN" <cugini at icst-ecf>
Just frinstance, no other language I know of that has
recursion speaks of "different bindings of the same variable" to
explain what's going on with the parameter list of a recursively
invoked function. The CL terminology conjures up the image of one
object with a changeable property, rather than of different objects,
each of which is referred to by the same name at different times.
This usage is consistent with the usage in mathematics, and with Alonzo
Church's terminology in his paper on lambda calculus. To a
mathematician or logician, a variable is a name like "x". A variable
"varies" exactly because it DOES have different bindings at different
times, e.g. at different steps of a recursion. It is computer
scientists who have perverted the sense of the word and use it to mean
what ought to be called a location.
∂07-Feb-87 2120 DALY@IBM.COM defstruct (resent due to lossage)
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 7 Feb 87 21:20:27 PST
Date: 6 February 1987, 12:08:19 EST
From: "Timothy P. Daly" <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <020687.120819.daly@ibm.com>
Subject: defstruct (resent due to lossage)
How can I define data structures that are pairs using defstruct?
How can I define data structures that contain pairs? What I want
to say is:
(defstruct (name (:type cons)) a b)
how can I name subfields?
(defstruct name (a :type cons :field-names '(kar kdr)))
Tim Daly
DALY@IBM.COM
∂07-Feb-87 2205 RAM@C.CS.CMU.EDU defstruct (resent due to lossage)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Feb 87 22:04:53 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sun 8 Feb 87 01:04:50-EST
Date: Sun, 8 Feb 1987 01:04 EST
Message-ID: <RAM.12277318498.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "Timothy P. Daly" <DALY@IBM.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: defstruct (resent due to lossage)
In-reply-to: Msg of 6 Feb 1987 12:08:19 EST from Timothy P. Daly <DALY at ibm.com>
Date: 6 February 1987, 12:08:19 EST
From: Timothy P. Daly <DALY at ibm.com>
To: common-lisp at sail.stanford.edu
Re: defstruct (resent due to lossage)
How can I define data structures that are pairs using defstruct?
How can I define data structures that contain pairs? What I want
to say is:
(defstruct (name (:type cons)) a b)
Believe it or not, there are some things you just can't do in Common
Lisp; this is one of them. Generally, if CLTL doesn't say that you
can do a thing, then it is not possible.
Rob
∂08-Feb-87 1203 Masinter.pa@Xerox.COM Re: Format for cleanup proposals
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Feb 87 12:03:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 FEB 87 15:35:47 PST
Date: 7 Feb 87 15:38 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Format for cleanup proposals
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
6 Feb 87 23:06 EST
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870207-153547-4323@Xerox>
I like most of your edits. I still would like the proposal label (a) to
start with a name in the CLtL index, and (b) be suitable for use as a
file name under Unix, so that I can use them as file names.
We'll probably just assign numbers as we submit things to X3j13, so the
submitters need not.
- - - - - Format, rev 3 - - - - - - - -
<<General notes:
Be brief: leave testimonials and personal opinions to the discussion at
the end. Be complete: do not expect someone else to fix or redesign
something. >>
Proposal label:
< A short descriptive label. Your label should start with something
which occurs in the index of CLtL, and be suitable for use as a file
name, e.g., cdr-termination.>
Reference:
< The pages of CLtL which describe the Common Lisp feature being
discussed, if such a reference exists. Other references where
appropriate. >
Version: <Initially version 1, updated for each revision.>
Edit history: <Original author and date of submission, and author and
date of subsequent revisions.>
Description of the problem:
<A description of the problem being addressed. Why is the current
situation unclear or unsatisfactory? Avoid describing the proposal
here.>
Category:
< One of the following:
CLARIFICATION - proposal to resolve an ambiguity or case of
under-specified situation in CLtL, where this ambiguity interferes
with portability of code.
CHANGE - Proposal for an incompatible change to the language.
ENHANCEMENT - Proposal for a compatible extension to the language. >
Description of Proposal:
< Describe as precisely as possible what you are proposing. Ideally,
this should take the form of text that could be dropped into CLtL or
some new specification document. You may propose a set of numbered
alternatives here, rather than one single proposal. Each proposal must
be a complete design; do not leave out details. Avoid arguing for the
proposal here, just describe it.>
- - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - -
Arguments for proposal
<Note: if more than one proposal is listed, provide the information
requested separately for each choice.>
Current practice: < Do some/many/no Common Lisp implementations already
work this way? Survey independent Common Lisp implementations.>
Cost of adopting change: <What is the cost to implementors of adopting
the proposal? How much implementation effort is required? Is
public-domain code available? For pervasive changes, can the conversion
be automated?>
Benefits of adopting change: <What are the benefits of adopting the
proposal? How serious is the problem if just left as it is? >
Cost of converting existing code: <For incompatible changes, what is the
cost of converting existing user code? To what extent can the process
be automated?>
Esthetics: <How does this proposal affect the simplicity
of the language, ease of learning, etc.>
Discussion:
<Any additional arguments, discussions, endorsements, testimonials, etc.
should go here.>
∂08-Feb-87 1422 FAHLMAN@C.CS.CMU.EDU Format for cleanup proposals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Feb 87 14:22:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 8 Feb 87 17:23:00-EST
Date: Sun, 8 Feb 1987 17:22 EST
Message-ID: <FAHLMAN.12277496569.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Format for cleanup proposals
In-reply-to: Msg of 7 Feb 1987 18:38-EST from Masinter.pa at Xerox.COM
Well, the argument for having a number and also a descriptive phrase was
that both could be used in the header of relevant messages. The numbers
would be useful for searching, while the phrases would tell what the
issue is really about. I'm afraid that what will happen if we try to
kill two birds with one stone is that people will choose labels that are
too terse to be memorable. Which would you rather see in a message
header:
"Issue 37: Must Cdr Terminate?"
"cdr-termination"
But it's probably not worth arguing about this. If doing it some
particular way makes your job as chairman easier, the decision should be
yours.
I don't think it always makes sense to require that the label ALWAYS
start with something in the index of CLtL. Many things we will want to
discuss have no pre-existing referent; a few have referents that didn't
end up in the index.
I also don't think it is sufficient to say that the label must be
suitable for a file name. What are the rules on the system you have in
mind? Is it case sensitive? What characters are legal in a filename?
What is the maximum length (varies from one unix to another).
-- Scott
∂09-Feb-87 0453 cugini@icst-ecf variable/binding terminology
Received: from ICST-ECF.ARPA by SAIL.STANFORD.EDU with TCP; 9 Feb 87 04:53:12 PST
Date: 9 Feb 87 07:37:00 EST
From: "CUGINI, JOHN" <cugini@icst-ecf>
Subject: variable/binding terminology
To: "common-lisp" <common-lisp@sail.stanford.edu>
Reply-To: "CUGINI, JOHN" <cugini@icst-ecf>
> Me: no other language I know of that has
> recursion speaks of "different bindings of the same variable" to
> explain what's going on with the parameter list of a recursively
> invoked function.
>
> From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
>
> This usage is consistent with the usage in mathematics, and with Alonzo
> Church's terminology in his paper on lambda calculus. To a
> mathematician or logician, a variable is a name like "x". A variable
> "varies" exactly because it DOES have different bindings at different
> times, e.g. at different steps of a recursion. It is computer
> scientists who have perverted the sense of the word and use it to mean
> what ought to be called a location.
whatever... the practical issue is whether the primary audience for
a CL standard is going to be logicians or computer scientists, whether
perverting or ... oh you know. It seems clear to me that for every
logician who nods in approval of this theoretically correct usage,
there will be 100 confused computer scientists/programmers, etc.
Assuming also that logicians are smarter than computer scientists,
both democracy and charity recommend using "normal" programming
language lingo.
John Cugini <Cugini@icst-ecf>
------
∂09-Feb-87 0524 MATHIS@ADA20.ISI.EDU Re: Format for cleanup proposals
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 9 Feb 87 05:24:34 PST
Date: 9 Feb 1987 05:23-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: Format for cleanup proposals
From: MATHIS@ADA20.ISI.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 9-Feb-87 05:23:51.MATHIS>
In-Reply-To: <870207-153547-4323@Xerox>
Larry, How do you want to report to the full committee? The
"format" seems like a good starting point and if you could add a
couple of issues discussed this way, that might be about right
for the Palo Alto meeting. As to mailing documents, I can send
you labels or you might go in with the objects mailing Gabriel is
doing.-- Bob
∂09-Feb-87 1104 hoey@nrl-aic Complex infinities
Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 9 Feb 87 11:04:27 PST
Date: 9 Feb 1987 10:33:10 EST (Mon)
From: Dan Hoey <hoey@nrl-aic.ARPA>
Subject: Complex infinities
To: common-lisp@su-ai.ARPA
Cc: edsel!bhopal!jonl@su-navajo.ARPA, Cassels@scrc-STONY-BROOK.ARPA
Message-Id: <539883191/hoey@nrl-aic>
Date: Fri, 6 Feb 87 19:47:04 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
...Now, the significant question is what to do about complex infinities.
I have some current needs for the two rational infinities -- one of
which is to model floating-point exactly -- but I don't have any ideas
at all about the complex domain. Do you?
Proposal: For complex floating infinities, use z/0 such that |z| = 1.
For complex rational infinities, let z have relatively prime integer
parts. The format for reading and printing such infinities is #I(r)
for real infinities r/0, and #I(r i) for the complex infinities
#C(r i)/0. As with rationals, convert to canonical form on input. The
name of the function to reconstruct z from z/0 should probably be
called something like RATIONAL-SIGNUM. This function (which is useful
even without infinities) coincides with SIGNUM except for rational
complex arguments, where it returns a complex number with relatively
prime integer parts and the same phase as its argument.
I am tempted to propose #I(0) as some pseudo-arithmetical object (NAN?)
that can be created but not operated on, or which becomes
arithmetically contagious under user control. Maybe someone who uses
NAN's can tell me whether this is the right way to do them.
Date: Wed, 4 Feb 87 09:27 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
...Note that it depends on what sort of calculation you're doing whether
infinity is an appropriate answer or not. One of the reasons that
rational infinities aren't in Common Lisp yet is that there is some
debate about whether rational infinity is affine (signed) or projective
(unsigned).
I hadn't heard the debate, but I know the answer: ``it depends on what
sort of calculation you're doing.'' But you can do projective
arithmetic on an affine system (coerce to positive infinity with ABS or
some to-be-proposed automagic), whereas there's no way to do affine
arithmetic on a projective system. I find this argument more
compelling than IEEE compatibility for having the system support the
affine case. (Cases like cot(0) where there is no unique affine answer
can return the principal affine answer--which turns out to be the
projective answer!)
With complex numbers there are at least three possible answers (based
on the compactification of the plane into a disc (affine), a projective
plane (projective, but now there are many infinities), or a sphere
(where there is only one infinity)). The affine model I propose above
is the most general, and it can be coerced to the one-infinity model
with ABS. You can coerce to the projective model with
(defun PROJ(z)
(if (or (minusp (imagpart z))
(and (zerop (imagpart z))
(minusp (realpart z))))
(- z)
z))
for IMAGPART, REALPART, ZEROP, and MINUSP suitably extended to the
infinities.
Dan
∂10-Feb-87 0800 Cassels@STONY-BROOK.SCRC.Symbolics.COM Rational Infinity
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Feb 87 07:56:47 PST
Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 66877; Tue 10-Feb-87 10:32:28 EST
Date: Tue, 10 Feb 87 10:33 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Rational Infinity
To: edsel!bhopal!jonl@navajo.stanford.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8702060633.AA03285@bhopal.edsel.com>
Message-ID: <870210103346.3.CASSELS@KRYPTON.SCRC.Symbolics.COM>
Date: Thu, 5 Feb 87 22:33:00 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Re: The existence of infinite rational objects and how they come about are
two separate issues. . . .
Very good point.
Re: . . . One of the reasons that
rational infinities aren't in Common Lisp yet is that there is some
debate about whether rational infinity is affine (signed) or projective
(unsigned).
Although Common Lisp doesn't require IEEE floating-point capability, I
think most people would agree that it's a reasonable goal to reach for.
For compability with the infinities available there, one would like to
have both +1/0 and -1/0 (I presume we can agree on a canonical form
for a rational infinity, that its denominator should be 0 and its
numerator's magnitude should be 1 ?)
The fact that your floating-point has a representation of infinity
doesn't need to imply that rational numbers do. Floating-point gets
along just fine by itself. Note that the contagion rules specify that
if (IEEE) floating infinity is combined arithmetically with a rational
number, the result is floating-point. The user must explicitly coerce
floating-point numbers to rational, and it could just be an error to
coerce an infinity to rational. [That's what we do at Symbolics.]
IEEE floating-point infinities serve two purposes -- to represent the
results of overflow, and to represent the results of some "illegal
operations" (like 1.0/0.0). That's probably the best reason for not
introducing rational infinities. Since rational arithmetic doesn't
overflow, associating rational infinities with IEEE infinities would
confuse the distinction between the two IEEE uses of infinity.
The only reasons I can see for rational infinities are:
1. Some algorithms like to have "infinities" for use in comparisons.
2. You want something to do when the user attempts to coerce a
floating infinity to rational, other than signal an error.
3. You really want arithmetic in a rational domain which includes
infinity.
1 is an okay reason, but NIL and T can serve almost as well. IEEE
infinities can be used just as easily, if you make mixed-mode
comparisons do the right thing. [If you blindly coerce to
floating-point, you may overflow a large rational value to a floating
infinity.]
Supposing that you decide that 2 is your reason. Then you also need a
way to represent NaNs. I suppose the natural representation is 0/0, but
that seems to be going a little far.
3 would be a fine reason, but then you have to deal with the
affine/projective question, and you've gotten far away from your
original goal. [And farther out on a limb than I'm willing to go.]
-- JonL --
- Bob.
∂10-Feb-87 2141 edsel!bhopal!jonl@navajo.stanford.edu Rational Infinity
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Feb 87 21:41:38 PST
Received: by navajo.stanford.edu; Tue, 10 Feb 87 21:40:45 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA09484; Tue, 10 Feb 87 21:15:37 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA09284; Tue, 10 Feb 87 21:20:54 PST
Date: Tue, 10 Feb 87 21:20:54 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8702110520.AA09284@bhopal.edsel.com>
To: navajo!Cassels%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: Robert A. Cassels's message of Tue, 10 Feb 87 10:33 EST
Subject: Rational Infinity
Re: . . . Since rational arithmetic doesn't
overflow, associating rational infinities with IEEE infinities would
confuse the distinction between the two IEEE uses of infinity.
The only connection I saw for "IEEE" was that it provided both negative
and positive infinities. Dan Hoey has provided the best reasoning I've
seen so far for subscribing to an affine system; and Larry Masinter made
a good case for wanting to separate out the infinity representation
from and already-overloaded T and NIL.
Re: The user [can] explicitly coerce
floating-point numbers to rational, and it could just be an error to
coerce an infinity to rational. [That's what we do at Symbolics.]
. . .
2. You [may[ want something to do when the user attempts to coerce
a floating infinity to rational, other than signal an error.
That's a sticky point -- floating infinities do show up under "normal"
circumstances, but Nan's don't. Providing a reasonable rational
representation for the floating infinities is a necessity when
converting back and forth.
One can carry the similarities too far; I certainly don't want to hear
about the inability to represent negative and positive fixnum zeros (even
though IEEE format has them). Long Live twos's-complement arithmetic!
-- JonL --
∂11-Feb-87 2032 DLA@DIAMOND.S4CC.Symbolics.COM Proposed Change to REMPROP and REMF
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 11 Feb 87 20:31:59 PST
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 55938; Wed 11-Feb-87 23:28:09 EST
Date: Wed, 11 Feb 87 23:27 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: Proposed Change to REMPROP and REMF
To: CL-Cleanup@SU-AI.ARPA
cc: DLA@DIAMOND.S4CC.Symbolics.COM, Masinter.pa@Xerox.COM,
Fahlman@c.cs.cmu.edu
References: <870201145656.6.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870201191334.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>,
<870201194844.8.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870201230831.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<870202054252.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM>,
<870202074933.2.MARGULIES@REDWING.SCRC.Symbolics.COM>,
<870202092747.9.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870202102514.6.DLW@CHICOPEE.SCRC.Symbolics.COM>,
<870202105732.2.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870202124724.0.DLW@CHICOPEE.SCRC.Symbolics.COM>,
<870203030917.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM>,
<870203102822.2.PTW@BIG.S4CC.Symbolics.COM>,
<870203105431.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>,
<870203111450.4.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870203141628.7.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870203174335.5.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870203175352.1.KHS@TANAGER.S4CC.Symbolics.COM>,
<870203182126.4.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>,
<870203204601.5.RETI@WESER.SCRC.Symbolics.COM>,
<870203204347.4.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<870203203541.8.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870203210502.9.SCRC|DLA@LIMPKIN.S4CC.Symbolics.COM>,
<148813.870203.___047@AI.AI.MIT.EDU>,
<870203233204.1.DLA@LIMPKIN.S4CC.Symbolics.COM>,
<148894.870204.___005@AI.AI.MIT.EDU>,
<870204105246.2.HORNIG@WINTER.SCRC.Symbolics.COM>,
<FAHLMAN.12276384296.BABYL@C.CS.CMU.EDU>,
<870204121313.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>,
<870204123259.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM>,
<FAHLMAN.12276430880.BABYL@C.CS.CMU.EDU>,
<870204200257.6.DLA@LIMPKIN.S4CC.Symbolics.COM>,
<149642.870205.MLY@AI.AI.MIT.EDU>,
<870205-161039-2777@Xerox>,
<539560403/hoey@nrl-aic>,
<FAHLMAN.12276674308.BABYL@C.CS.CMU.EDU>,
<870205203355.967711@BCO-MULTICS.ARPA>,
<8702060036.AA20215@aerospace.aero.org>,
<870206053142.271474@HIS-PHOENIX-MULTICS.ARPA>,
<870206100113.3.DLW@CHICOPEE.SCRC.Symbolics.COM>,
<870206095318.9.DLA@LIMPKIN.S4CC.Symbolics.COM>,
<FAHLMAN.12276898296.BABYL@C.CS.CMU.EDU>,
<870206150837.1.DLA@LIMPKIN.S4CC.Symbolics.COM>,
The message of 6 Feb 87 13:41 EST from System Files <SYS@SAIL.STANFORD.EDU>,
<8702062003.AA05166@aerospace.aero.org>,
<8702061908.AA00074@blacksox.edsel.uucp>,
<870207142505.8.DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870210205446.9.DLA@LIMPKIN.S4CC.Symbolics.COM>,
<870211005316.8.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<870211100617.4.DLW@CHICOPEE.SCRC.Symbolics.COM>,
<870211115318.4.DLA@LIMPKIN.S4CC.Symbolics.COM>
Message-ID: <870211232753.1.DLA@LIMPKIN.S4CC.Symbolics.COM>
Issue: REMF-DESTRUCTION-UNSPECIFIED
Version: 1
Source: DLA@SCRC-STONY-BROOK.SCRC.Symbolics.COM
Reference: GET (SETF), REMPROP, GETF (SETF), REMF, pp. 165-167.
NREVERSE, p. 248.
DELETE, DELETE-IF, DELETE-IF-NOT, DELETE-DUPLICATES,
NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT, pp. 254-256.
NCONC, NRECONC, p. 269.
NBUTLAST, p. 271.
NSUBST, NSUBST-IF, NSUBST-IF-NOT, p. 274.
NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR, p. 276-279.
... This list may be incomplete ...
Description: Currently, the exact nature of the list modification
performed by REMF and REMPROP is not specified. Conversation on the
Common-Lisp mailing list has made it clear that this situation is not
good. The list modification allowed should either be specified, or
explicitly documented as unspecified and up to the individual
implementation. If the list modification is specified, then programmers
can rely on the specification. If it is unspecified, then implementors
can take advantage of that to make their implementation more efficient.
This argument can be made for most of the destructive functions
specified above, and possibly others, so they are included as
references.
Category: clarification
------------------------------------------------------------
Proposal: REMF-DESTRUCTION-UNSPECIFIED:DONT-SPECIFY
I propose that CLtL's documentation on each of the above functions
include a statement such as the following: "This function performs a
modification to the top-level [list] structure of its argument(s).
Different implementations may choose different modifications of the list
structure, as long as the function otherwise fulfills its contract. It
is an error to rely on the list destruction being performed in any
particular way. Any references to the list structure of the argument(s)
other than the value(s) returned are therefore undefined after the function
returns."
Rationale and Advantages: Implementations can improve performance of
many of the referenced functions when they are not under the constraint
to implement them in a specified fashion or "in the most logical
fashion". For example, on the Symbolics 3600, DELETE of a cdr-coded
list could use the implementation primitive %CHANGE-LIST-TO-CONS rather
than RPLACD to avoid creating forwarding pointers. As another example,
all of the destructive operations which remove objects could remove CAR
pointers to removed objects which are more volatile than the list
itself, assisting the garbage collector.
Most of the referenced functions implement abstract operations, for
example REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are currently in such danger, and this change to the documentation would
just publicize it. The clarification would ENCOURAGE good programming
practice by warning people to only obey the published contract of the
referenced functions.
Symbolics Common Lisp already implements some of the functions in a
non-obvious fashion. For example, in Symbolics Common Lisp:
(setq foo (list 'a 'b 'c)) ==> (a b c)
(setq bar (cdr foo)) ==> (b c)
(setq foo (delete 'b foo)) ==> (a c)
bar ==> ((c)) ; most people would guess (b c).
(eq (cdr foo) (car bar)) ==> t
There is no cost of adopting this change to developers.
------------------------------------------------------------
Alternative: REMF-DESTRUCTION-UNSPECIFIED:DO-SPECIFY
Some or all of the functions could be documented to
perform the list destruction in a specified manner.
Rationale and Advantages: (1) The "additional features" may be more
useful to some programmers. (2) Programmers may expect the functions to
do the "expected" destructive operation. (3) Compatibility with other
dialects. For example, it may be easier to port a Zetalisp program to
Common-Lisp if REMPROP returns a sublist pointer as defined in Zetalisp.
If this alternative is pursued, then many implementations may be forced
to incompatibly change what their functions do. This may break existing
programs and may cause the implementation to have poorer performance.
------------------------------------------------------------
Alternative: REMF-DESTRUCTION-UNSPECIFIED:DO-NOTHING
Rationale and Advantages: I can think of no advantages other than
expediency.
If the issue is left unresolved, then implementations may be forced to
be too inefficient, or programmers may unexpectedly rely on undocumented
behavior of the functions, or both.
------------------------------------------------------------
Voting:
Discussion:
∂12-Feb-87 1423 shebs%utah-orion@utah-cs.arpa *APPLYHOOK* Vagueness
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 12 Feb 87 14:22:52 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA29796; Thu, 12 Feb 87 15:24:29 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA17872; Thu, 12 Feb 87 15:24:25 MST
Date: Thu, 12 Feb 87 15:24:25 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8702122224.AA17872@utah-orion.ARPA>
To: common-lisp@sail.stanford.edu
Subject: *APPLYHOOK* Vagueness
Page 322 of CLtL is a little vague on exactly when *applyhook* is used.
It says that the apply hook function is used only for "ordinary" functions,
while funcalls and some related cases are not hookable. I would like to know
what an "ordinary" function is - does it include named local functions
created via flet? What about an anonymous lambda in the car of a form?
stan
∂12-Feb-87 1631 SINGER@SPAR-20.ARPA Lexical globals
Received: from [128.58.1.2] by SAIL.STANFORD.EDU with TCP; 12 Feb 87 16:31:51 PST
Date: Thu 12 Feb 87 16:31:23-PST
From: David Singer <SINGER@SPAR-20.ARPA>
Subject: Lexical globals
To: common-lisp@SAIL.STANFORD.EDU
cc: singer@SPAR-20.ARPA
Message-ID: <12278568528.12.SINGER@SPAR-20.ARPA>
I am unable to work out how to declare LEXICAL, GLOBAL variables; DEFVAR
makes special variables -- what I am looking for is a variable which will
obscured by another declaration in say, a LET construct. Am I missing
something obvious, or is common-lisp (which is I understand 'normally'
lexical) missing this concept, which would equate to STATICS in other
block-structured lexical languages such as BCPL and pascal-family languages?
-------
∂12-Feb-87 1656 FAHLMAN@C.CS.CMU.EDU Lexical globals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Feb 87 16:55:57 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 12 Feb 87 19:56:48-EST
Date: Thu, 12 Feb 1987 19:56 EST
Message-ID: <FAHLMAN.12278573146.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Lexical globals
In reply to: David Singer <SINGER at SPAR-20.ARPA>
Common Lisp is currently missing this concept. There has been some
discussion on how to remedy this, but no clear consensus as yet.
-- Scott
∂12-Feb-87 1714 Moon@STONY-BROOK.SCRC.Symbolics.COM *APPLYHOOK* Vagueness
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Feb 87 17:14:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 69836; Thu 12-Feb-87 20:13:10 EST
Date: Thu, 12 Feb 87 20:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *APPLYHOOK* Vagueness
To: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8702122224.AA17872@utah-orion.ARPA>
Message-ID: <870212201305.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 12 Feb 87 15:24:25 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Page 322 of CLtL is a little vague on exactly when *applyhook* is used.
It says that the apply hook function is used only for "ordinary" functions,
while funcalls and some related cases are not hookable. I would like to know
what an "ordinary" function is - does it include named local functions
created via flet? What about an anonymous lambda in the car of a form?
"Ordinary function" isn't a term defined in CLtL as far as I can tell,
but from context it means a genuine function, as opposed to a macro or
a special form. Whether the function is defined globally, locally, or
explicitly with a lambda-expression makes no difference. I hope that in
the future some consistent terminology will be used for the various
things that can appear in the car of a form, so that these problems of
ambiguity don't keep arising.
The business about funcall and mapcar is expanding on the "within eval"
portion of the phrase "application of ordinary functions within eval".
That is, applyhook controls only the application of the function
designated by the car of a form to the arguments resulting from
evaluating the forms in the cdr of the form.
∂13-Feb-87 1737 Masinter.pa@Xerox.COM Re: Proposed Change to REMPROP and REMF
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Feb 87 17:37:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 87 14:42:12 PST
Date: 13 Feb 87 14:20 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Proposed Change to REMPROP and REMF
In-reply-to: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>'s message
of Wed, 11 Feb 87 23:27 EST
To: DLA@DIAMOND.S4CC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870213-144212-1035@Xerox>
We've changed the form a bit -- I think its stabalized, but yours is
only the second that has come in. I'd like to ask you to recast your
proposal in the new format.
First:
Your reference list is nice, but since, as you point out, it may be
incomplete, just referencing the entire Steele chapter would be better.
Second:
I'd really like you to complete the Rationale section (which is now
labelled Arguments for the proposal) discussing each point separately. I
think that it helps people to see each proposal in the same format. As
it stands, its not clear how you addressed the issues of cost/benefit
tradeoff directly.
It would be nice to send yours out with the packet of "sample"
proposals, so if you could do this quickly, it would help. If you have
trouble with any of these parts, please let me know.
Thanks,
Larry
- -- - Format Proposals to "clean up" Common Lisp. Format, Revision 4 -
- - - - - - -
<<General notes:
Be brief: leave testimonials and personal opinions to the discussion at
the end. Be complete: do not expect someone else to fix or redesign
something. >>
Proposal label:
< A short descriptive label. Your label should start with something
which occurs in the index of CLtL, and be a suitable symbol in the
Common Lisp style, e.g., cdr-termination.>
Reference:
< The pages of CLtL which describe the Common Lisp feature being
discussed, if such a reference exists. Other references where
appropriate. >
Version: <Initially version 1, updated for each revision.>
Edit history: <Original author and date of submission, and author and
date of subsequent revisions.>
Description of the problem:
<A description of the problem being addressed. Why is the current
situation unclear or unsatisfactory? Avoid describing the proposal
here.>
Category:
< One of the following:
CLARIFICATION - proposal to resolve an ambiguity or case of
under-specified situation in CLtL, where this ambiguity interferes
with portability of code.
CHANGE - Proposal for an incompatible change to the language.
ENHANCEMENT - Proposal for a compatible extension to the language. >
Description of Proposal:
< Describe as precisely as possible what you are proposing. Ideally,
this should take the form of text that could be dropped into CLtL or
some new specification document. You may propose a set of numbered
alternatives here, rather than one single proposal. Each proposal must
be a complete design; do not leave out details. Avoid arguing for the
proposal here, just describe it.>
- - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - -
Arguments for proposal, as follows:
<Note: if more than one proposal is listed, provide the information
requested separately for each choice.>
1. Current practice: < Do some/many/no Common Lisp implementations
already
work this way? Survey independent Common Lisp implementations.>
2. Cost of adopting change: <What is the cost to implementors of
adopting
the proposal? How much implementation effort is required? Is
public-domain code available? For pervasive changes, can the conversion
be automated?>
3. Benefits of adopting change: <What are the benefits of adopting the
proposal? How serious is the problem if just left as it is? >
4. Cost of converting existing code: <For incompatible changes, what is
the
cost of converting existing user code? To what extent can the process
be automated?>
5. Esthetics: <How does this proposal affect the simplicity
of the language, ease of learning, etc.>
Discussion:
<Any additional arguments, discussions, endorsements, testimonials, etc.
should go here.>
∂16-Feb-87 1240 Masinter.pa@Xerox.COM Re: Format for cleanup proposals
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Feb 87 12:40:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 FEB 87 12:39:13 PST
Date: 16 Feb 87 12:45 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Format for cleanup proposals
In-reply-to: MATHIS@ADA20.ISI.EDU's message of 9 Feb 87 05:23 PST
To: MATHIS@ADA20.ISI.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870216-123913-2179@Xerox>
My notion is to mail out the format, and a couple of the proposals that
we've gotten in that format. The report at the meeting will explain the
charter of the group ("to filter proposals and reject universally
unacceptable ones, and recommend action when there is a consensus", and
"to deal with changes to the programming language of Common Lisp, and
not the terminology with which it is described").
I think the format should get one document ID, and the packet of
"sample" proposals should get another one (rather than a separate
document ID for each proposal).
The issues which seem ready for discussion are IMPORT-UNCLEAR,
FLET-IMPLICIT-BLOCK, SEQUENCE-FUNCTION-EXCLUDE-ARRAYS,
ADJUST-ARRAY-DISPLACEMENT, DO-SYMBOLS-DUPLICATES, and TAILP-NIL.
The discussion on lexical environments is on hold -- Dave Moon has
offered to produce a more complete proposal for dealing with
GET-SETF-METHOD-ENVIRONMENT and friends.
I would like to have a discussion at the meeting about policies for
handling issues of enhancement and resolution of ambiguities.
∂16-Feb-87 1950 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Format for cleanup proposals
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Feb 87 19:50:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71764; Mon 16-Feb-87 22:48:55 EST
Date: Mon, 16 Feb 87 22:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Format for cleanup proposals
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870216-123913-2179@Xerox>
Message-ID: <870216224851.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
[Mathis removed]
Date: 16 Feb 87 12:45 PST
From: Masinter.pa@Xerox.COM
The discussion on lexical environments is on hold -- Dave Moon has
offered to produce a more complete proposal for dealing with
GET-SETF-METHOD-ENVIRONMENT and friends.
I don't remember offering to do this. That's not to say that I didn't
offer to do it, but it does suggest that you shouldn't hold your breath
waiting.
∂17-Feb-87 0653 MATHIS@ADA20.ISI.EDU Re: Format for cleanup proposals
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 17 Feb 87 06:52:53 PST
Date: 17 Feb 1987 06:52-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: Format for cleanup proposals
From: MATHIS@ADA20.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]17-Feb-87 06:52:36.MATHIS>
Larry's suggested report is of the type I was expecting, but only
the rest of you on this mailing list can evaluate if the topics
mentioned are really near resolution. Larry needs replies. --
Bob
∂17-Feb-87 1012 JAR@AI.AI.MIT.EDU Format for proposals to "clean up" Common Lisp
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Feb 87 10:12:50 PST
Date: Tue, 17 Feb 87 13:14:43 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Format for proposals to "clean up" Common Lisp
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-reply-to: Msg of 16 Feb 87 09:38 PST from Masinter.pa at Xerox.COM
Message-ID: <155380.870217.JAR@AI.AI.MIT.EDU>
Thanks, I'll try to do a global lexicals proposal before the March
meeting at least. Let me know if there's some other significant
deadline I should try to meet.
∂18-Feb-87 0949 RPG Lexical globals
∂14-Feb-87 0801 JAR@AI.AI.MIT.EDU Lexical globals
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 14 Feb 87 08:01:24 PST
Date: Sat, 14 Feb 87 11:02:53 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Lexical globals
To: Fahlman@C.CS.CMU.EDU
cc: rpg@SAIL.STANFORD.EDU, masinter@XEROX.COM,
willc%tekchips.tek.com@RELAY.CS.NET, kmp@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of Thu 12 Feb 1987 19:56 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <154375.870214.JAR@AI.AI.MIT.EDU>
Date: Thu, 12 Feb 1987 19:56 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Common Lisp is currently missing this concept. There has been some
discussion on how to remedy this, but no clear consensus as yet.
Has there ever been consensus on ANY question discussed on that list,
other than the most trivial and obvious things? It seems clear that the
mailing list is not a good way to make progress on just about anything,
and that even looking for consensus on the list is a lost cause.
Is there a committee on the global lexicals question? Has a proposal on
the issue been submitted to X3J13? If not I'd be willing to draft one.
This particular question is an especially annoying one in the context of
a scheme compatibility package (my current interest), and is really the
only thing other than tail recursion and continuations which can't be
handled by purely local transformations (i.e. macros). (There's also
the question of nontrivial expressions in function position, but I think
that consensus will emerge in favor of that with less effort.)
It was my impression that Xerox is also anxious to make progress on this
issue (because of deep binding). If the question is presented clearly,
I think we might even be able to get agreement from people like Moon and
Weinreb who have trouble understanding this sort of thing.
Jonathan
∂14-Feb-87 1308 FAHLMAN@C.CS.CMU.EDU Lexical globals
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Feb 87 13:08:00 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 14 Feb 87 16:08:36-EST
Date: Sat, 14 Feb 1987 16:08 EST
Message-ID: <FAHLMAN.12279055877.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: kmp@SCRC-STONY-BROOK.ARPA, masinter@XEROX.COM, rpg@SAIL.STANFORD.EDU,
willc%tekchips.tek.com@RELAY.CS.NET
Subject: Lexical globals
In-reply-to: Msg of 14 Feb 1987 11:02-EST from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
Has there ever been consensus on ANY question discussed on that list,
other than the most trivial and obvious things? It seems clear that the
mailing list is not a good way to make progress on just about anything,
and that even looking for consensus on the list is a lost cause.
Well, there are two distinct issues here: reaching a consensus or
near-consensus (i.e. no objections from anyone who deserves to be taken
seriously -- use your own filter on that one), and turning this
consensus into a stable decision that people can count on. We've done
the former several times. The latter we have not managed to do since
CLtL was finalized, though we're trying yet again with the X3J13
committee.
My point was that the last time this lexical global business was
discussed, several different ways of treating this were put forward, and
then the issue faded away without resolution. So in this case, there is
even less consensus than usual. Perhaps a good, workable, well-reasoned
proposal would resolve it, however.
Is there a committee on the global lexicals question? Has a proposal on
the issue been submitted to X3J13? If not I'd be willing to draft one.
Sounds very useful. One might argue that this should go to the
Lisp1/Lisp2 subcommittee, since this issue must be resolved if Common
Lisp is ever to become a Lisp1. However, I think it would be worthwhile
to add this mechanism even if Common Lisp remains a Lisp2, so probably
this issue should go to the "cleanup" subcommittee, of which Masinter is
chairman. He can tell you about the format he would like incoming
proposals to follow.
-- Scott
∂19-Feb-87 1949 cugini@icst-ecf What does TYIPEEK mean?
Received: from ICST-ECF.ARPA by SAIL.STANFORD.EDU with TCP; 19 Feb 87 19:49:30 PST
Date: 19 Feb 87 12:59:00 EST
From: "CUGINI, JOHN" <cugini@icst-ecf>
Subject: What does TYIPEEK mean?
To: "common-lisp" <common-lisp@sail.stanford.edu>
Reply-To: "CUGINI, JOHN" <cugini@icst-ecf>
I recently got Forgy's OPS5 interpreter, written in fairly
Common Lisp, running on our VAX (under VMS). When I ran
it thru the VAXLisp compiler, there were a few error messages,
most of which I can handle (eg, spell GREATERP as ">"),
but there were several references to an undefined TYIPEEK function,
like 'frinstance:
;;; RHS Functions
(defmacro accept (&rest z)
`(prog (port arg)
(cond ((> (length ',z) 1.)
(%warn '|accept: wrong number of arguments| ',z)
(return nil)))
(setq port t)
(cond (*accept-file*
(setq port ($ifile *accept-file*))
(cond ((null port)
(%warn '|accept: file has been closed| *accept-file*)
(return nil)))))
(cond ((= (length ',z) 1)
(setq arg ($varbind (car ',z)))
(cond ((not (symbolp arg))
(%warn '|accept: illegal file name| arg)
(return nil)))
(setq port ($ifile arg))
(cond ((null port)
(%warn '|accept: file not open for input| arg)
(return nil)))))
;; HERE'S ONE
(cond ((= (tyipeek port) -1.)
($value 'end-of-file)
(return nil)))
(flat-value (read port))))
(defun span-chars (x prt)
;; HERE'S ANOTHER
(do ((ch (tyipeek prt) (tyipeek prt)))
((not (member ch x #'char-equal))) (read-char prt)))
I think this may be left over from MacLisp. Is the following an
OK implementation?
(defun tyipeek (port)
(peek-char nil port nil -1.))
Thanks for any advice....
John Cugini <Cugini@icst-ecf>
------
∂22-Feb-87 1459 FAHLMAN@C.CS.CMU.EDU Compiler proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Feb 87 14:59:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Feb 87 18:00:16-EST
Date: Sun, 22 Feb 1987 18:00 EST
Message-ID: <FAHLMAN.12281173374.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Compiler proposal
Gentlemen:
Rob Maclachlan has produced a comprehensive proposal for cleaning up the
abiguities in the compiler area. I think his proposal handles almost
all of the open issues in that area, and it looks very good to me. I
might add that Rob is currently working on a new optimizing compiler for
the RT (easily retargetable to other stock hardware), so he has not
proposed anything that cannot be easily implemented, at least in a
system like ours. People might not like a few of the details of the
proposal, but it's a valuable piece of work in any event, since it sets
up a framework in which all these issues can be considered.
The compiler subcommittee (except for Rob) seems to be moribund -- more
so even than cleanup. It was probably a mistake to set up compiler and
cleanup as separate committees: it dilutes the pool of energetic people
willing to do some work and the pool of people with enough
implementation experience to see any problems. In any event, I think we
cleanup people should take a close look at Rob's proposal because it
impinges on some of the issues that we are dealing with on our side.
I will forward that proposal to you in a separate (long!) message.
Rob's proposal make require some tuning and debate, but it is too
valuable a piece of work to get bogged down in a non-funcitoning
committee. We should probably devise some way of circulating it widely
among the concerned parties within X3J13 and of debating any points
about the proposal that people find difficult.
Rob is on the cl-cleanup list, as an observer, so if we want to discuss
some of these points among ourselves, he will be able to particpate.
-- Scott
∂22-Feb-87 1501 FAHLMAN@C.CS.CMU.EDU Rob's Proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Feb 87 15:00:43 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Feb 87 18:01:31-EST
Date: Sun, 22 Feb 1987 18:01 EST
Message-ID: <FAHLMAN.12281173600.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Rob's Proposal
COMPILER CLEANUP PROPOSAL #2
This proposal attempts to clarify the implications of compilation for Common
Lisp. This is done largely by adding restrictions that Common Lisp programs
must obey. In this proposal, a "Common Lisp program" is a program that runs
in all implementations of Common Lisp. Our goal in the proposal is to define
Common Lisp program so that the meaning of a Common Lisp program is insensitive
to legal variations in the implementation of evaluation and compilation.
It isn't derogatory to say that a program isn't a Common Lisp program; it
simply says that result of executing the program may vary unpredictably from
one implementation to another. There is no such thing as a "non-portable
Common Lisp program."
In this proposal, "Common Lisp function" means a function defined in the
standard, not an arbitrary function written in Common Lisp. It is an error to
globally redefine any Common Lisp function, macro or special form. This is
really common sense, since there is no way that a portable program can be sure
that a given redefinition won't interfere with another program, or even destroy
the system it is running in.
The nature of the programming environment supported by an implementation
strongly interacts with properties of the implementation that we are concerned
with in this proposal. Since one of Common Lisp's goals is to allow a wide
range of programming environments, we will try to avoid unnecessarily
constraining the programming environment. When we cannot avoid environment
issues, we will require Common Lisp programs to assume the simplest
environment.
In a number of cases, we allow the compiler to use static information to make
decisions at compile time that most current implementations postpone until run
time. Implementations will presumably still provide a programming environment
that allows for incremental redefinition, but a Common Lisp program has only
limited access to these facilities since it must work in any programming
environment.
Currently all that CLTL really says about the semantics of compilation is that
the semantics of a compiled program is the same as that of an interpreted
program "so far as possible". Unfortunately, many apparently legal programs
behave differently when compiled than when interpreted. This is a fundamental
property of compilation, rather than a problem which can be "fixed" by changing
the compiler.
The heart of this proposal is a revised version of the rules for evaluation in
Common Lisp. The concept of "time of evaluation" is used to discuss the
currently ill-specified way in which the meaning of some parts of a program may
determined before run time. Time of evaluation means basically the same thing
as "time of binding" in the standard programming language literature. This
phrasing is used both to avoid confusion with the Lisp concept of binding names
to variables and also to emphasize the similarity to a generalized concept of
evaluation.
The purpose of a compiler is to avoid effort at run time by evaluating some
expressions at compile time that an interpreter would have to evaluate at run
time. We will call evaluation done at compile time "early evaluation" and
evaluation at run time "late evaluation". In a standard interpreter, early
evaluation and late evaluation are concurrent.
Early evaluation in the compiler has two major effects on the semantics of
programs:
-- Expressions which are evaluated at compile time are not affected by run-time
redefinition, so if a given expression is evaluated early in a compiled
program and evaluated late in an interpreted program, the behavior of the
programs will differ if the run-time value of the expression is different
from the compile-time value. For example, in many implementations
redefining Car will affect an interpreted program but not a compiled one.
-- Programs must allow some expressions to be evaluated at compile time so
that the compiler can function. For example, macros must be defined at
compile time and must function properly in an environment that may be
substantially different from the run-time environment.
How do we make the language well defined in the presence of this fundamental
difference? An unsatisfactory solution is specify the semantics of both the
compiled and interpreted versions. This approach cannot work since it would
require us to specify the time of evaluation of all possible expressions in the
language. This would be conceptually complex, and would also unnecessarily
constrain the implementation.
Our approach is to allow the compiler great freedom in choosing time of
evaluation, and then to require legal programs to be insensitive to the time of
evaluation. Programs may only rely on the time of evaluation when it is
explicitly specified.
!
Evaluation:
Evaluation is a process that takes a Lisp data structure and interprets is as
a Lisp program. There is a little appreciated and poorly defined dividing line
here: at some critical instant data becomes program. Since this proposal only
concerns itself with programs, we must determine at what point a data structure
becomes a program. These are the rules for determining when a data structure
is "promoted" to a program:
-- Passing a form as the argument to Eval or as the definition argument to
Compile promotes the form to a program. This rule also applies to forms
that are implicitly evaluated when they are typed into the read-eval-print
loop or read from a code file.
-- When a macro is expanded during evaluation, the result is promoted to a
program. The form argument passed to a macro function during evaluation
has already been promoted to a program. The same rules apply to these
other macro-like forms: Deftype, Defsetf and Define-Setf-Method.
-- Writers of read macros should consider the result to be promoted to a
program when the top-level read call that invoked it returns, since
programs often evaluate the result of Read.
Once a form has been promoted to a program, the system may do early evaluation
on any part of the form at any time, subject to the normal rules for early
evaluation.
It is an error to destructively modify any part of a Lisp data structure that
has been promoted to a program. This rule subsumes the "illegal to modify
constants" rule, since it says that it is illegal to modify any part of a
program, even if it is not a subform of a Quote special form. The symbols
mentioned in a program are not considered part of the program in that it is
legal to modify the definitions associated with them.
When the system promotes a data structure to a program, it may
non-destructively replace any part of the program with any structurally
equivalent data structure that is known to be unmodifiable. (Structurally
equivalent equals Equal if it descends into structures and arrays.) In
particular, since the system knows that both program fragments and newly
allocated structure cannot be side-effected, this rule subsumes the "sharing of
constants may be added or removed" rule. Normally Eval does not do
substitutions in this way, since it can cause obscure effects in the
read-eval-print loop and has no corresponding benefits.
!
Compilation:
We recast CLTL's equation of compiled and interpreted semantics in the
following way:
(eval '<form>) <=> (funcall (compile nil '(lambda () <form>)))
Compile is a way for the user to suggest that the implementation do its best to
early evaluate subforms of the form. The above equivalence is just a special
case of the requirement that a Common Lisp program work correctly in all legal
implementations; it says that if a Common Lisp system has both "interpreted"
and "compiled" implementations of evaluation, then the program must work
equally well in both implementations.
If the switch *Compile-Definitions* is true, this suggests to the
implementation that defining forms containing code should be compiled even when
encountered by eval.
!
Time of evaluation:
With these exceptions, all forms in Common Lisp are only late evaluated:
-- Any reference to a variable that is defined to be constant in the early
evaluation environment may be early evaluated. The implementation
must guarantee that the results of all references to the same constant will
be Eql during late evaluation. Since it is an error to redefine a constant
between early and late evaluation, the Eql relation might not be preserved
in programs that redefine constants.
-- Any form whose first element names a macro in the early evaluation
environment may be replaced with its macroexpansion by early evaluation.
Early evaluation cannot be done directly on the subforms of a macro call,
since the evaluator does not know what the syntax of the macro is. This is
why macro definitions must be present in the early evaluation environment;
early evaluation is impossible without macroexpansion.
Since Setf is a macro, this implies that the Setf method present during
early evaluation may determine the meaning of a use of Setf.
-- If a form is not a special form, lexical function or local macro call,
and is not a global macro in the early evaluation environment, then it may
be assumed to be a global function call:
(foo x y z) => (funcall (symbol-function 'foo) x y z)
-- If a form is a call to a function that has an inline expansion in the early
evaluation environment and has inline calling enabled, then early
evaluation may replace the form with an application of the inline expansion
to the arguments. This transformation must be done in a way that preserves
the lexical environment present at the time of definition of the function.
Early evaluation may be done on the expansion either when it is defined or
when it is used, so any environment that inline calls to a function are
early evaluated in must contain everything needed to early evaluate the
original definition of that function. For example, macros might not be
expanded in the recorded inline expansion, so appropriate macro definitions
must be present in the early evaluation environment of the inline calls.
Any of the standard Common Lisp functions might have an inline expansion.
It should be possible to disable any inline expansion using Notinline, but
it is not possible for a Common Lisp program to tell if standard functions
have been expanded inline since it is an error to redefine Common Lisp
functions. In implementations where it is meaningful to redefine standard
functions, Notinline provides a standard mechanism for ensuring that the
new definition is called.
-- A Defun form defining a function that has not been declared Notinline may
be enclosed in a Labels form lexically defining the name to have the
same definition. The Labels form may be placed around any enclosing
form within the entire form being early evaluated. This transformation
must be done in a way that preserves the original lexical environment of
the Defun. For example, this transformation is legal:
(progn
(defun fun (x) <body>)
(defun fun2 () (fun))
...)
=>
(labels ((fun (x)
<body>))
(progn
(defun fun (x) <body>)
(defun fun2 () (fun))
...))
This transformation allows "block compilation" of calls to functions
defined within the same form. In the above example, the compiler might be
able to compile Fun2 more efficiently since the definition of Fun is
lexical, and thus cannot be changed. For example, the compiler might elect
to jump directly to the lexically apparent definition of Fun rather than
indirecting through the global symbol definition cell.
If for some reason it is important to call the current global definition of
a function, then the function should either be declared notinline before it
is defined or explicitly called globally by saying:
(funcall 'fun ...)
This transformation can only affect calls that appear in the same form as a
Defun for the same name, but note that the Compile-File reference model
combines entire files into a single form. Implementations are encouraged
to provide a way to inhibit any block compilation so that incremental
redefinition can be done during development.
Rationale: although I know of no existing implementations that exploit the
full generality of this transformation, many compile self-calls as a simple
jump. This proposal allows for this optimization, and also permits future
compilers to do inter-routine optimization. Few portable programs depend
on the ability to redefine functions on the fly, so requiring use of the
global definition to be explicitly forced should not cause major problems.
-- A reference to a type defined at compile time using Deftype may be replaced
with the expansion of that reference. For example, if this definition is
present during early evaluation:
(deftype natural (n) `(integer 0 ,n))
Then early evaluation could make this transformation:
(the (natural 3) x) => (the (integer 0 3) x)
Any type specifier argument to a Common Lisp function may also be expanded
in this way if it is Constantp during early evaluation. For example, this
transformation is legal:
(typep x '(natural 3)) => (and (integerp x) (<= 0 x 3))
If a reference is made to a type that is defined to be a structure in the
early evaluation environment, then early evaluation may make
transformations that assume the same structure definition will be present
during late evaluation. Two structure definitions are considered
equivalent if the Defstruct forms are identical and the definitions of any
included structures are equivalent.
For example, given these definitions:
(defstruct a)
(defstruct (b (:include a)))
These transformations would be legal:
(typep x 'a) => (a-p x)
(typep (the b x) 'a) => t
The above transformations only exploit the type hierarchy, which rarely
changes. Many implementations will also assume that the same slots will be
present in the same order during late evaluation, allowing slot accessors
to be expanded inline. This makes redefinition of structures during
incremental development difficult. CLTL implies that this behavior can be
controlled by using the Notinline declaration, but this is untrue, since
there is no way to inhibit inline expansion of the slot setters.
Implementations are encouraged to have a debug mode for Defstruct that
makes minimal assumptions about structure definitions during early
evaluation and does full type checking of structure and slot values.
It is *not* legal for an implementation to signal an error simply because a
type is unknown at early evaluation time, since the type might be defined
at some later time. Users should bear in mind that early evaluation will
work better when all referenced types are defined, but there are some cases
where use before definition cannot be avoided. For example, structure
definitions for recursive data structures may need to use types that have
not yet been defined in slot type declarations. It is reasonable to emit
compiler warnings about unknown types, since they are often caused by
typing errors of a different type.
-- Declarations of global variable and function type made by Proclaims in
the early evaluation environment may be exploited by early evaluation.
For example, given the declarations:
(proclaim '(integer int))
(proclaim '(function fun (float) float))
Early evaluation could do these transformations:
int => (the integer int)
(fun x) => (the float (fun (the float x)))
(fun int) => (error "Wrong type argument.")
-- Lambda and the Flet, Labels, Let and Let* special forms may use the
early evaluation environment to determine whether to make special or
lexical bindings. This implies that if a variable is globally special
during early evaluation of the binding form, it must also be globally
special during late evaluation of that form. Similarly, if a variable is
lexical during early evaluation, then it may not be declared globally
special at late evaluation time.
It is an error for a variable to be declared constant during the early (or
late) evaluation of a binding of that variable.
-- Time of evaluation may be explicitly controlled using the Early-Eval,
Early-Eval-Only and Late-Eval-Only special forms. Some macros and function
calls are evaluated early as though in an implicit Early-Eval special
form.
Note that in the in the above rules, a statement that that a thing *may* be
early evaluated implies that it also *may not*, thus it is an error for the
compile time and run time environments to differ in a way that would produce
different results depending on the time of early evaluation. A Common Lisp
implementation may assume that programs have this property, possibly producing
results that could not result from either a strict compiler or interpreter
evaluation strategy. That is, a program that is sensitive to evaluation time
may die in arbitrarily bizarre ways. For example, given these definitions:
(defconstant const 3)
(defun fun () (* const 3))
(defconstant const 5)
A call to Fun is not required to return either 9 or 15. Conceivable reasonable
implementations might return 25, and an unreasonable (but still legal)
implementation might crash the machine.
!
Control of evaluation time:
Eval-When is replaced by three new special forms: Early-Eval, Early-Eval-Only
and Late-Eval-Only. If one of these forms evaluates its body, it returns the
values of the last form, otherwise it returns NIL.
By default, forms are only evaluated during late evaluation (at run time.)
Early-Eval-Only causes the forms within the body to be evaluated only during
early evaluation; presumably they are definitions that are not needed at run
time. If Early-Eval-Only appears within a Late-Eval-Only form, then the body
is not evaluated at all.
Late-Eval-Only prevents early evaluation of any of its forms, regardless of any
implicit or explicit early evaluation normally associated with the forms. This
is useful primarily for inhibiting the implicit early evaluation of forms which
cannot be properly evaluated until run-time.
Early-Eval causes the forms within the body to be evaluated during both early
and late evaluation. Early-Eval may appear within a Early-Eval-Only or
Late-Eval-Only form, but it is equivalent to a Progn in this context; it has no
effect on time of evaluation.
There is no form that causes the body to be evaluated using the default
evaluation rules since it is not meaningful to re-enable early or late
evaluation once it has been inhibited by an enclosing form.
There is a rough equivalence between the old Eval-When situations and the
proposed forms:
Early-Eval corresponds to Eval-When (Compile Load Eval).
Early-Eval-Only corresponds Eval-When (Compile Eval).
Late-Eval-Only is similar to Eval-When (Load Eval), but also has the effect
of inhibiting any early evaluation of subforms.
!
Manipulating the early evaluation environment:
Early evaluation is done to all forms in the same way, no matter where the form
appears. This is in contrast to many existing Lisp implementations which only
early evaluate defining forms when they appear "at top level" in a code file.
Top-level forms have no special semantics in Common Lisp; defining forms may
appear absolutely anywhere. The commonly understood top-level Compile-File
semantics are a special case of the general semantics consistently used
everywhere.
Some forms change the environment in a way that affects the early evaluation
process. These forms must somehow make their definitions available to the
compiler so that it can do early evaluation properly. This is done by
evaluating the defining forms during the early evaluation process, as though
they had appeared in an implicit Early-Eval. Common Lisp programs must be
written so that forms that affect the early evaluation environment are always
early evaluated before any forms that depend on the environment changes.
If F1 and F2 are any two subforms of the form being early evaluated, F1 is
guaranteed to be early evaluated at least once before the early evaluation of
F2 if:
1] F1 appears textually before F2 in the form being early evaluated, and
2] During late evaluation of the form, F1 is always evaluated at least once
before F2 is evaluated.
These two requirements allow the implementation to collapse the early and late
evaluation steps.
We make no guarantee of the order of early evaluation other than these rules.
In particular, since F1 may be early evaluated more than once, it may be early
evaluated both before and after F2. A perverse compiler could early evaluate
all forms in textual order, and then early evaluate them again in random order.
This implies that is an error for conflicting definitions to be made during
early evaluation, since it is undefined which definition will be current at the
time of early evaluation of the forms that depend on the definition. For
example, it is an error for different Deftypes with the same name to be present
in the same evaluated form.
This arbitrary reordering may only be done within the early evaluation of a
single form, but note that the Compile-File reference model combines entire
files into a single form. When the early evaluation environment is only
manipulated by defining forms that appear at top level in a code file these two
rules are equivalent, since top level forms are evaluated in textual order at
load time.
These forms have an implicit Early-Eval:
defmacro
deftype
defstruct
define-setf-method
defsetf
defconstant
proclaim
defun
Note that the value for Defconstant must be evaluatable at compile time.
In Defun, the code that manipulates the inline expansion for the function is
evaluated early, but the function definition itself is not placed in the early
evaluation environment.
A Proclaim form is only early evaluated if the argument is Constantp. A
Proclaim may appear anywhere, but the rules for indeterminacy of the order of
early evaluation also apply, implying that the declaration might only affect
the forms late evaluated after it, or may affect as much as the entire form
being early evaluated. In the case of call policy (Inline, Notinline, ...) and
Optimize proclamations, compilers are encouraged (but not required) to apply
the declaration only to the code textually between the Proclaim and any
succeeding proclamation that contradicts it.
A definition or proclamation need not be directly "seen" by the compiler to
take effect in the compiler environment. For example, it is legal to say:
(early-eval-only
(require 'phlogiston))
Any definitions in the loaded file will be available for the early evaluation
of subsequent forms. This implies that the compiler cannot assume that all
definitions and proclamations will pass through it; it must either carefully
watch the Lisp environment or communicate with the implementations of the
defining forms.
It is an error to setf Symbol-Function or Macro-Function during early
evaluation. Definitions may only be made in the compiler's function namespace
by using Defun and Defmacro.
The early evaluation environment for Compile is identical to the Lisp
environment that Compile was called in. Definitions in the calling environment
are available for early evaluation during Compile, and side effects of early
evaluation affect the original Lisp environment. This follows directly from
the equivalence of Compile and Eval.
The early evaluation environment for Compile-File is *not* required to be the
same as the environment that Compile-File was called in, but it *may* be. Side
effects of early evaluation may or may not affect the original environment.
Implementations are encouraged to use a clean Compile-File environment
containing no user definitions. This implies that a Common Lisp program must
explicitly establish any definitions required in the compiler environment; this
is what the header forms in a code file are for.
!
Code file syntax:
A code file is a file that contains the textual representation of a portion of
a Common Lisp program. A code file may be compiled using Compile-File, or may
be loaded directly using Load.
A code file is interpreted as a sequence of lisp forms, as read by Read. At
the beginning of the file are the "header forms" which specify information
needed to read and compile the forms in the rest of the file. The header forms
are composed of calls to certain special environment manipulation functions.
The header forms end when a form that cannot be a header form is encountered.
A Common Lisp program may do these package operations during compilation or
loading, but only as header forms:
Make-Package
In-Package
Shadow
Shadowing-Import
Export
Unexport
Use-Package
Unuse-Package
Import
It is illegal to do any of these package operations during compilation or
loading:
Unintern
Rename-Package
These functions may also be used as header forms:
Provide
Require
Use-Readtable
The Use-Readtable header form is used to specify the readtable to be used when
reading subsequent forms. Use-Readtable is equivalent to a Setq of *Readtable*
to its argument. Since both Load and Compile-File bind *Readtable*, the effect
of a Use-Readtable header form will be confined to the reading of the code
file in which it appears. Note that Early-Eval (which replaces Eval-When)
cannot be used to manipulate the readtable since early evaluation might not be
interleaved with reading.
!
The Compile-File reference model:
The semantics of Compile-File are based on the general semantics of evaluation
that we have already established. Compile-File introduces a number of
complications because it must parse a code file and then unparse the result
into an output file that can be reconstructed by Load in a different Lisp
environment.
In order to help with the definition of the semantics of Compile-File and
subsequent Load of the output file, we define a degenerate version of
Compile-File that exhibits most of the interesting properties of this
operation.
To implement Compile-File:
-- Bind *readtable* to the standard readtable, *package* to the "USER"
package, *print-base* and *read-base* to 10, *print-circle* to NIL and
*print-array* to T.
-- Read and evaluate forms until a form is encountered that is not a header
form.
-- Print the header forms into the output file, with *package* bound to some
package that has no accessible symbols. If a Use-Readtable form appears,
omit it so that reading done by the loader is not affected by any reader
customizations.
-- Read the rest of the forms in the input file and make them into a big
Progn.
-- If desired, do early evaluation on the Progn and its subforms, subject
to the usual rules for early evaluation.
-- Print the resulting form into the output file, translating "#," into "#.".
User supplied structure-print functions are ignored so that structures are
always printed readably. "#=" and "##" are used as needed to ensure that
all references to each uninterned symbol are still EQ when the form is
read.
Multiple files may be compiled in the same environment by specifying a list of
files to Compile-File instead of a single file. If :Output-File is specified
in this case, then Compile-File produces a *single* output file containing the
results of all of the compilations.
If Compile-File is given a list of input files and there are distinct output
files, then we just loop over the input files, doing distinct compilations in
the same environment. If a single output file is specified by using
:Output-File, then we can create it simply by concatenating the individual
output files, or we can compile all the code as a unit by reading all the files
before we do early evaluation, putting all the header forms of all the files at
the beginning of the output file and accumulating all the code in the Progn.
To implement Load:
-- Bind *readtable* to the standard readtable, *package* to the "USER" package
and *read-base* to 10.
-- Read and evaluate forms until EOF.
This definition of Load can be used to load both user code files and the text
files generated by Compile-File (which might not technically be code files if
we concatenated output files.)
These are completely legal implementations of Compile-File and Load; all Common
Lisp programs must work correctly with this implementation. Furthermore, all
implementations of Compile-File must produce results equivalent to the
reference model when compiling legal programs. We can make this equivalence
because we have moved most of the uncertainty of compilation into the
definition of evaluation.
Due to the reading, processing and printing, it is *not* true that loading a
compiler output file is the same as loading the source. Here are some
implications of the reference model for programs compiled with Compile-File:
-- It is an error for a program fragment (such as a constant) to be
unprintable. Circular structures are not printable in the reference model.
-- Unprintable aspects of object type such as array displacement or element
type may be lost. However, printable aspects of object type must be
preserved. For example, bit-vector constants must still be bit-vectors
when the output file is loaded.
-- If the package structure is different at load time than it was at compile
time, then a symbol may end up somewhere other than where the original
qualifier would have placed it. This is because the symbol is printed
qualified with its home package (if at all), while the original
qualification in the code file might have been in another package.
-- Early evaluation may be done at load time rather than (or in addition to)
at compile time or at run time. This is because the Progn representing
the code in the file is evaluated when the file is loaded, giving the
system license to early evaluate any subforms of that form (subject to the
normal rules for early evaluation.)
!
Inline declarations:
The "inline expansion" for a function is conceptually a copy of the Lambda
expression that is the definition of that function. Early evaluation can
replace calls to the function with uses of the corresponding definition,
reducing function call overhead and opening the way for optimizations based on
the calling context. The old Inline and Notinline declarations are defined in
terms of the new Inline-Level and Inline-Expansion declarations.
(inline-level <n> <name>*)
Set the inline expansion level for each function <name> to <n>, where <n>
is a number between 0 and 3. The theory is that if <n> is greater than the
value of the Space quality to the Optimize declaration, then inline
expansion will be considered. The initial inline expansion level for user
functions is 1, allowing the function to be expanded inline if an expansion
is available and space is not important.
If <n> is 0, inline call is forbidden, so a full function call must be
done.
(inline-expansion <name>*)
Allow a function to be expanded inline somewhere by causing the expansion
of the next Defun for each <name> to be recorded. This is only legal as a
proclamation.
(notinline <name>*)
is a synonym for (inline-call 0 <name>*).
(inline <name>*)
is a synonym for (inline-call 2 <name>*). When Inline appears as a
proclamation, it also implies Inline-Expansion for the named functions.
Instead of directly enabling and disabling the inline expansion of individual
functions, it is better practice to manipulate the time/space tradeoff
explicitly by using the Optimize declaration.
Since inline expansion may be implemented by substitution with the source,
providing an inline expansion for a recursive function may cause early
evaluation not to terminate. The inline expansion for local functions defined
by Flet and Labels is always available, but the initial inline expansion level
for local functions is 0 to avoid possible problems with recursive definitions.
It is legal to provide an inline expansion for a Defun in a non-null lexical
environment, but the user should bear in mind that few compilers will attempt
inline expansion in this case.
An implementation is never required to expand calls inline; ideally the
decision is based on the current compiler policy specified by the Optimize
declaration. Defun is also not required to record an inline expansion, but if
it does not record a new inline expansion it must clear any old one. The
recording or clearing of inline expansions is also done during late evaluation
of Defuns, so loading a file containing the definitions of functions declared
inline should make the inline expansions available for early evaluation in that
environment.
!
Optimize declarations:
The qualities for the optimize declaration may be any non-complex number
between 0 and 3 inclusive. Compilers are encouraged to numerically compare the
qualities to evaluate particular compilation tradeoffs, rather than using a
specific numeric value for a quality to enable a particular optimization. For
example, the compiler should not generate unsafe code to gain speed unless
Speed is greater than Safety. When two compared optimization qualities are
equal, the default action should be taken. Setting all optimize qualities to 1
should have the effect of restoring the system default. 0 and 3 retain the
meaning of "totally unimportant" and "extremely important". Since the
optimization qualities contradict each other, it is not a good idea to specify
more than one to be 3.
*No* combination of optimization settings should cause an otherwise functional
program to stop working; safety is optional but correctness is required. Here
are some "optimizations" that a Common Lisp compiler may not make:
-- Assuming that any integer-valued operation must result in a Fixnum when this
is not known by declaration and cannot be proven by examining the code.
For example,
(1+ (the fixnum x))
may result in a bignum, and although
(the fixnum (+ (the fixnum x) (the fixnum y) (the fixnum z)))
must result in a fixnum, the intermediate sum might be a bignum.
-- Transforming arithmetic expressions in ways that might violate float
contagion. For example, this transformation is not in general legal if
some of the arguments may be floats:
(* x (* y z)) => (* x y z)
-- Doing code motion that could cause code to be erroneously executed in
correct programs. For example, moving a division by the loop iteration
count out of a loop would cause a division by zero error when the count is
zero, yet the error would never happen in the "unoptimized" program.
Common Lisp compilers may have magic switches that cause them to stop being
Common Lisp compilers, but these switches must not be enabled by legal Optimize
declarations.
The Brevity optimize quality may be used to control the verbosity of compiler
warning messages. High values of this quality inhibit warnings, while low
values enable them. This quality should be compared with the other qualities
to enable specific kinds of warnings. For example, efficiency notes are
enabled when Speed > Brevity, and notes about questionable constructs are
enabled when Safety > Brevity.
When the Brevity quality is 3, warnings may only be printed for these reasons:
-- If a form cannot possibly be evaluated legally, for example:
(do be do)
(cons (get 'foo x 'y))
(car 3)
If an error is detected during compilation, the erroneous form should be
compiled so that it signals an error if it is evaluated at run time,
perhaps by replacing it with a call to Error. Warnings about calls to user
functions are forbidden when Brevity is 3, since the run time definition
could be changed to allow anything.
-- If a lexical variable is never referenced and is not declared Ignore. [The
exact semantics here depends on what the cleanup committee decides to do
with Ignore and Ignorable.]
-- If a global variable reference is made to a symbol that has not been
declared special or constant.
The purpose of these restrictions is to allow programs to be compiled in
systems other than the one they were developed in without producing large
numbers of spurious warnings. Implementors are encouraged to generate any
warnings that will assist in writing correct, efficient and portable programs,
but these warnings must be controlled by the Brevity quality.
!
Type declarations:
The existence of a type declaration should not be taken as license to generate
unsafe code. Historically, Lisp compilers have tended to do this, making
declarations in impediment to writing correct code, rather than an aid.
A type declaration is simply an assertion about the meaning of a program;
safety is a property of the implementation of that program, and the
desirability of safety depends on the way that the program is being used. It
should be possible to write a program with declarations and debug it safely.
After the program is totally bug free (!), unsafe but fast compilation may be
specified by an Optimize proclamation. Ideally a type declaration should
simply cause the compiler to emit code to verify that the declaration is true.
As long as all the declarations are true, it is not an error for multiple type
declarations to be made for the same variable or expression. This means that
multiple declarations imply an intersection of the types of the individual
declarations:
(declare (integer x) (type (rational 0) x)) =>
(declare (type (and integer (rational 0)) x))
In this example, we can infer that X must be a non-negative integer. If the
there is no intersection between the two types, this amounts to declaring the
variable to be of type NIL. Since no value is of type NIL, and the initial
value must be of the specified type, the binding itself is in error.
∂22-Feb-87 1854 FAHLMAN@C.CS.CMU.EDU Cleanup committee charter
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Feb 87 18:54:25 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Feb 87 21:55:03-EST
Date: Sun, 22 Feb 1987 21:55 EST
Message-ID: <FAHLMAN.12281216114.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Cleanup committee charter
In-reply-to: Msg of 16 Feb 1987 15:45-EST from Masinter.pa at Xerox.COM
The report at the meeting will explain the
charter of the group ("to filter proposals and reject universally
unacceptable ones, and recommend action when there is a consensus", and
"to deal with changes to the programming language of Common Lisp, and
not the terminology with which it is described").
We haven't really discussed the charter of this group explicitly. I
don't really disagree with Larry's description, but I would shift the
emphasis a bit.
It seems to me that what this subcommittee needs to do is to put forth a
coherent, well debugged set of proposals that we think should be
adopted. Certainly we should also pass along alternative proposals, and
if we deadlock on some issue we should just pass along both options
along with the argument for each. It is not our place to make any final
decisions, but I think there has to be some leadership on these
technical issues, and I think that has to come from us. If we just
collect a laundry list of random proposals and pass them along, all we
are doing is shifting the problem of technical analysis to a body too
ponderous to handle it.
I also feel that, while we should leave the spec-writing to others, our
committee cannot completely avoid questions of terminology. Some of the
ambiguities we are dealing with and some of the messes we must clean up
are best fixed by clearly sorting out the relevant concepts and hanging
a good label on each. And some of these terms will poke through into
Common Lisp itself. For example, if we adopt the view that "special
form" refers to the whole list and "special operator" refers to the
symbol that is the car of that list, then we want to rename
SPECIAL-FORM-P to SPECIAL-OPERATOR-P. We shouldn't get into the
business of writing sections of the manual, but I think we're as good a
group as any to define what various technical terms are supposed to
refer to.
We've got a much more serious problem, and I think that it is essential
that we develop a plan for handling it before we all get to Palo Alto.
This committee is not making much progress for the simple reason that we
don't have a critical mass of active people on this committe. We don't
have enough people to produce the proposals, and we never hear from most
of the committee members when a proposal is put forward.
As I understand it, Jonl has withdrawn. RPG mentioned that some other
Lucid person, perhaps Eric Benson might join, but this hasn't happened
yet.
KMP has been totally incommunicado, and Dave Matthews nearly so;
I'm not sure whether this is because of mail system lossage or lack of
time, but the effect is the same in any case.
It seemed at the Dallas meeting that Guy was joining this group rather
reluctantly, and he has been awfully quiet, though he did answer my "are
you there?" message with the axolotls in it.
Dave Moon stated when he joined up that most of his Common Lisp time
would have to go into the object committee rather than cleanup. The
plan was that, for now at least, he would react to proposal but not try
to produce any. He has done that.
Larry is putting some effort into orgnization and administration. I
have put some effort into cleaning up the initial list of proposals. I
think that both of us are willing to shoulder a share of the load, but
not half of it.
I would suggest the following -- just an idea to kick around, subject to
change:
Masinter, Moon, and I remain on this cleanup committee. Guy, as a
soon-to-be officer of X3J13, moves to ex-officio-observer status, that
same as RPG and Mathis. The other members are removed from the cleanup
committee, though they are welcome to remain on the mailing list if they
want to observe what goes on and comment occasionally.
(If any of you object to being flushed and want to assume a more active
role in all this, and if your local mail system agrees, that would be
great. Just say so.)
Then we try to get four new people on this committee who will dig in and
do something. The best way to do this is probably to invite specific
people, rather than asking for volunteers from among the X3J13
membership -- that would be a pretty sure way to get another load of
dead wood. I can think of a few people who might be good in this role:
Rob Maclachlan, Eric Benson, and Skef Wholey. I'm sure that you can
think of others.
If we get some of these people to sign up, we can announce that fact at
the next meeting. If other X3J13 people want to join, we let them; if
they don't contribute, we flush them later. That way we avoid any
accusation of excluding people or companies. Balance is not too
important on this committee, since it does not have ultimate
decision-making power, but I think it's better to include a couple of
losers than to make a couple of enemies.
We may want to consider collapsing the compiler and cleanup committees
into one, flushing the inactive members from both.
Comments? Other suggestions? Axolotls?
-- Scott
∂23-Feb-87 1207 KMP@STONY-BROOK.SCRC.Symbolics.COM Cleanup committee charter
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Feb 87 12:07:04 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76773; Mon 23-Feb-87 15:05:05 EST
Date: Mon, 23 Feb 87 15:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Cleanup committee charter
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870223150316.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sun, 22 Feb 1987 21:55 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
... KMP has been totally incommunicado ... I would suggest the
following -- just an idea to kick around, subject to change: Masinter,
Moon, and I remain on this cleanup committee. ... If any of you object
to being flushed and want to assume a more active role ...
I dislike your use of the verb "flush" here. It has the very negative
connotations that I think are out of order.
I vote to have myself left on the list of active contributors.
In fact, I vote to have everyone left on the list. This committee's
charter is not to vote on things, so issues of quorum are pretty
irrelevant. Neither are issues of attribution. When all is said and
done, it will be obvious who has actively participated and who has not,
so there is also no point in prejudging this issue of who is "active"
and who is "passive".
People who are on the list should not be encouraged to say anything
unless they have something to say. Let's try not to create a climate in
which people think that verbosity is synonymous with participation.
Most of the mail which has crossed the list thus far has been
of two kinds: administrative and simple proposals.
I don't much care what format the proposals are in. I happen to not
be ecstatic about the format you guys are suggesting, but I don't
dislike them enough to make noise about it since I expect that further
discussion of any kind would just slow progress to no good end.
In truth, I feel obliged to read and carefully consider everything
anyone sends, and will do so regardless of the format. My mail reader
uses In-Reply-To and References fields, not subject lines, to track
what relates to what and it's easy enough to manually patch the few
messages that come in without those fields. That's enough for me.
As for the proposals that have crossed the list before this week,
the main reason that I've said nothing is that I've had nothing
particularly useful to say on them. I could send out messages like
Scott's that said "I read over this and it looks ok." but as someone
pointed out, this isn't really a forum for voting so it doesn't matter.
When time comes for voting, I'll be sure to participate. I think
the issues raised thus far have received adequate coverage either
by the individual who wrote the proposal or those who have chosen to
reply (mostly Moon, I guess). In any case, I saw no point in remarking
further.
I've been over this week's proposal from Rob about evaluation/compilation
and do have some comments on that which will follow later when I have
time to write them up.
Several times I've been on the verge of sending proposals of my own only
to find new mail in my mailbox on that day saying that the format of
proposals had changed once again. I hope we can agree that while there
is a desirable format, it's not important enough to hold up useful work.
I was dismayed that DLA (after all his careful work writing things up
to spec) was asked to represent his proposal in another format. This
kind of pickiness is likely to bog us down and be the real cause of
any failure on our part to produce. Rob's proposal is also not in the
"proper format" (if I correctly understand the current theory after all
the changes that keep getting made). I hope no one will ask him to waste
his time "fixing it" and that we can just work with what we've got.
By the way, on an unrelated note, I've just finalized my plane
reservations for California and will definitely be around for the
weekend before the meeting. I can be free Sunday afternoon if
someone wanted to go through with the idea of a face-to-face meeting
about any of this. I think a very reasonable thing that could be
accomplished at such a meeting would be to divide up Steele's list
of things that need addressing so that we didn't have to wonder who
was going to take responsibility for what.
∂23-Feb-87 1243 FAHLMAN@C.CS.CMU.EDU Cleanup committee charter
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 12:42:53 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Feb 87 15:43:39-EST
Date: Mon, 23 Feb 1987 15:43 EST
Message-ID: <FAHLMAN.12281410646.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Cleanup committee charter
In-reply-to: Msg of 23 Feb 1987 15:03-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Welcome back. When you failed even to respond to my "are you receiving
this mail?" message, I assumed that you were either not receiving the
mail, had fallen through the earth's crust, or that you were so
uninterested in this committee's work that you were not reading the
mail. I'm glad to learn that none of the above is true. I'm sorry that
it required a negative word like "flush" to get some kind of response
from you. Verbosity is not a virtue, but neither is a silence so
profound that it is indistiguishable from non-existence.
Your message was ambiguous on one point. Is it the case that you want
to participate in the work of this committee -- formulating proposals
and trying to work out some of the difficult issues -- or do you just
want to listen, complain about things you don't like, and vote when the
time comes? The point of my earlier message is that in order to make
significant progress, I think we need six or seven people on this
committee who plan to do some work on the generation side. Should we
count you as one of those? If not, you're what I was calling an
"obvserver", and we need to dig up some non-observers.
-- Scott
∂23-Feb-87 1301 KMP@STONY-BROOK.SCRC.Symbolics.COM Cleanup committee charter
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Feb 87 13:00:48 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 76861; Mon 23-Feb-87 16:00:31 EST
Date: Mon, 23 Feb 87 15:58 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Cleanup committee charter
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12281410646.BABYL@C.CS.CMU.EDU>
Message-ID: <870223155837.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 23 Feb 1987 15:43 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Your message was ambiguous on one point. Is it the case that you want
to participate in the work of this committee -- formulating proposals
and trying to work out some of the difficult issues -- or do you just
want to listen, complain about things you don't like, and vote when the
time comes? The point of my earlier message is that in order to make
significant progress, I think we need six or seven people on this
committee who plan to do some work on the generation side. Should we
count you as one of those? If not, you're what I was calling an
"observer", and we need to dig up some non-observers.
Count me as someone with intent to generate proposals. I've got a lot of
experience built up from converting MACSYMA to Common Lisp that I'm
looking to use as a basis. I have about 30 or so areas of manual
vagueness and need for extension (ranging in size from trivial to complex)
brought up specifically by MACSYMA that I'm interested in writing up as
soon as I can figure out what format to put things in. I am also content
to spend some time suggesting ways to resolve other issues such as those
mentioned by Steele (which may overlap in a few places on my 30 personal
favorites).
∂23-Feb-87 1323 FAHLMAN@C.CS.CMU.EDU Cleanup committee charter
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 13:23:15 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Feb 87 16:23:56-EST
Date: Mon, 23 Feb 1987 16:23 EST
Message-ID: <FAHLMAN.12281417979.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Cleanup committee charter
In-reply-to: Msg of 23 Feb 1987 15:58-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Count me as someone with intent to generate proposals.
Great! I think we may have had a funny deadlock situation here. I
suspect that one of the reasons there has been so much emphasis on
formats has been that we didn't feel we could make progress on anything
more substantive because only a couple of us seemed to be in the loop.
And now it appears that this administrative stuff has inhibited people
from joining in. Maybe soon we can get past this and get rolling.
I continue to feel that most (not all!) of these cleanup things are
really pretty easy: it doesn't matter too much which way they go, as
long as we get a decision one way or the other. So quick progress on
the majority of these issues should be possible -- only a few of them
present significant technical challenges.
Dividing up the issues list among some number of people seems like a
good way to start. Doing this in person would be OK if enough of us are
at the meeting; if that can't be arranged, then doing it by mail would
work better. I guess the first step is to get an inventory of how many
"actives" we have, and to decide whether we need to add some new ones.
-- Scott
∂23-Feb-87 1710 KMP@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Feb 87 17:09:54 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77151; Mon 23-Feb-87 20:10:08 EST
Date: Mon, 23 Feb 87 20:08 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870223200820.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Proposal: FORMAT-OP-C
References: WRITE-CHAR (p384), ~C (p389)
Category: CHANGE/CLARIFICATION
Edit History: Revision 1 by KMP 02/23/87
Problem Description:
The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should
be culturally compatible with the host environment." This description
is not very useful in practice.
I'm assuming the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose
that wasn't planned on:
(FORMAT NIL "~C" #\Space) might "Space" rather than " ".
[Anyone who would argue that the word `abbreviated' in the definition
was supposed to prevent this should just be happy that some implementors
didn't choose to interpret that word to mean that "Sp" should come back.]
Some implementations have (FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
As nearly as I can tell, the implementations which return "Space" treat
~C and ~:C equivalently. That seems like a waste of a FORMAT op.
Since the behavior of ~A is also vague on characters (a separate
proposal will address this), the only way to safely output a literal
character is to WRITE-CHAR; FORMAT does not suffice (unless you use
~Q of #'WRITE-CHAR -- which is generally neither pretty nor convenient).
Proposal (FORMAT-OP-C:WRITE-CHAR):
The vague wording about cultural compatibility should be struck from
the description of ~C. The description of ~C should be changed to simply
state that (FORMAT stream "~C" char) has the same effect as
(WRITE-CHAR char stream).
Some explanatory text should be added to the description of WRITE-CHAR
which admits the concept that non-standard characters may be presented
using different glyphs from implementation to implementation, but that
turning one character into many is not appropriate.
(Note: Someone very familiar with the problem of quoting issues for normal
and image mode terminals should probably review the description prior
to its acceptance to make sure that the wording doesn't forbid
reasonable behavior in that regard.)
Rationale:
I believe this was probably the intent of the authors.
It makes things clear enough that programmers can know what to expect.
Current Practice:
Implementations are divided. Some implementations have
(FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".
Adoption Cost:
Those implementations which did not already implement ~C as WRITE-CHAR
would suffer an incompatible change.
Benefits:
User code that uses ~C would have a chance of being portable.
As things stand, users who use ~C can't reliably port their code.
~C and ~:C would perform usefully distinct operations.
Conversion Cost:
Standard ``Query Replace'' technology for finding occurrences of
"~C" and changing them to "~:C" semi-automatically should suffice.
Aesthetics:
Making ~C do something well-defined will probably be perceived as
a simplification.
Discussion:
KMP thinks it's important to get this cleared up as soon as possible.
∂23-Feb-87 1741 Moon@STONY-BROOK.SCRC.Symbolics.COM FORMAT-OP-C
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Feb 87 17:41:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77179; Mon 23-Feb-87 20:42:08 EST
Date: Mon, 23 Feb 87 20:40 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870223200820.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870223204036.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
May I suggest an amendment? After reading the corresponding sections
of the CLtL and the Lisp Machine Manual, I believe the error in CLtL
is that it was not stated explicitly that the "implementation-dependent
abbreviated format" applies only to characters with non-zero char-bits.
Thus instead of removing the mumbling about cultural compatibility, I
suggest simply adding a sentence saying that ~C is the same as write-char
for characters with zero char-bits. I don't think we want to require
~C and write-char to do the same thing for characters with bits.
∂23-Feb-87 1819 FAHLMAN@C.CS.CMU.EDU FORMAT-OP-C
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 18:19:14 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Feb 87 21:11:20-EST
Date: Mon, 23 Feb 1987 21:11 EST
Message-ID: <FAHLMAN.12281470298.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FORMAT-OP-C
In-reply-to: Msg of 23 Feb 1987 20:40-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I like Moon's amendment. It would solve the #\SPACE problem, while
not contraining the freedom of implementations to do what they like with
the crockish bits attributes (which is where the cultural differences
come in). Truly portable code can't make use of bits anyway, so
allowing differences there doesn't hurt.
-- Scott
∂23-Feb-87 1922 KMP@STONY-BROOK.SCRC.Symbolics.COM PRINC-CHARACTER
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Feb 87 19:22:13 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77241; Mon 23-Feb-87 22:22:46 EST
Date: Mon, 23 Feb 87 22:20 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870223222057.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Proposal: PRINC-CHARACTER
References: PRINC (p383)
Category: CHANGE/CLARIFICATION
Edit History: Revision 1 by KMP 02/23/87
Problem Description:
The manual is not adequately specific about the function of PRINC
when given a character as an argument.
For example, does (PRINC #\Space) print ``Space'' or `` ''?
The advice that "the general rule is that output from PRINC is
intended to look good to people" is the root of a lot of the problem.
The truth is that what looks good varies with context. viz,
* In (FORMAT T "Foo~ABar" #\Space),
seeing "Foo Bar" looks better than seeing "FooSpaceBar" (to me).
* In (FORMAT T "Type ~C to continue" #\Space),
seeing "Type Space to continue" looks better than "Type to continue" (to me).
Proposal 1 (PRINC-CHARACTER:WRITE-CHAR):
(PRINC char stream) should be defined to be equivalent to (WRITE-CHAR char stream).
Proposal 2 (PRINC-CHARACTER:FORMAT-OP-COLON-C):
(PRINC char stream) should be defined to be equivalent to (FORMAT stream "~:C" char).
Proposal 3 (PRINC-CHARACTER:FORMAT-OP-C):
(PRINC char stream) should be defined to be equivalent to (FORMAT stream "~C" char).
[Depending on the outcome of another ballot item, this might turn out to be redundant
with one of the other proposals.]
Rationale:
The behavior of (PRINC char) should be well-defined. A hopefully well reasoned
but probably ultimately arbitrary decision is in order.
Current Practice:
As nearly as I can tell from a quick glance at the sources, Symbolics
uses PRINC-CHARACTER:WRITE-CHAR. (Moon will undoubtedly correct me if
I'm wrong.)
I'm sure I've seen other implementation(s) do differently, though offhand
I cannot remember which one(s). In any case, the wording in CLtL is
not clear enough to preclude such.
Adoption Cost:
Those implementations which did not already implement the choice decided upon
would suffer an incompatible change.
Benefits:
User code that uses PRINC (and presumably ~A) on characters would have
a chance of being portable.
Conversion Cost:
It's easy to search for occurrences of PRINC and ~A in code, but it may
not always be apparent when the argument is a character. Automatic conversion
is unlikely to succeed.
Aesthetics:
Making PRINC do something well-defined for as many primitive data types
as possible will probably be perceived as a simplification.
Discussion:
KMP thinks this is moderately important because it is embarrassing to have
common functions like this vary so widely in behavior between implementations.
He doesn't think it is critical because (if nothing else) it is only one of
many problems with the vague contract of PRINC.
∂23-Feb-87 1938 FAHLMAN@C.CS.CMU.EDU PRINC-CHARACTER
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 19:38:16 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 23 Feb 87 22:39:00-EST
Date: Mon, 23 Feb 1987 22:38 EST
Message-ID: <FAHLMAN.12281486260.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PRINC-CHARACTER
In-reply-to: Msg of 23 Feb 1987 22:20-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
For what it may be worth, CMU Common Lisp (a.k.a. Spice Lisp) also uses
PRINC-CHARACTER:WRITE-CHAR. Presumably most of the implementations
based on our code do this as well -- I don't think we've changed this
recently. We should check Lucid Lisp, but if they do it this way too,
then we seem to have the preponderance of existing practice on one side
of the issue. Vaxlisp may be the odd one, but we're not running it here
so I can't check.
I don't care which way this one goes, but I agree that it should be
nailed down. Other things being equal, I'd say that we follow the
majority of existing implementations.
-- Scott
∂23-Feb-87 2207 edsel!gypsy-moth!kdo@navajo.stanford.edu (READ-CHAR T) vs. (FORMAT T)
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 22:06:58 PST
Received: by navajo.stanford.edu; Mon, 23 Feb 87 22:05:53 PST
Received: from gypsy-moth.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA01351; Mon, 23 Feb 87 17:53:32 pst
Received: by gypsy-moth.edsel.com (3.2/SMI-3.2)
id AA01060; Mon, 23 Feb 87 17:50:39 PST
Date: Mon, 23 Feb 87 17:50:39 PST
From: edsel!gypsy-moth!kdo@navajo.stanford.edu (Ken Olum)
Message-Id: <8702240150.AA01060@gypsy-moth.edsel.com>
To: navajo!common-lisp%sail@navajo.stanford.edu
Subject: (READ-CHAR T) vs. (FORMAT T)
READ-CHAR and WRITE-CHAR accept T to mean *TERMINAL-IO*, but FORMAT
accepts T to mean *STANDARD-OUTPUT*. This leads easily to confusion,
since a higher-level output-function is likely to take a stream and
pass it on without examination to either FORMAT and to other
output-functions, and thus get output distributed between different
streams when *STANDARD-OUTPUT* is bound.
This is pretty unpleasant.
Ken
∂24-Feb-87 0742 gls@Think.COM FORMAT-OP-C
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 24 Feb 87 07:42:51 PST
Received: from boethius by Think.COM via CHAOS; Tue, 24 Feb 87 10:42:24 EST
Date: Tue, 24 Feb 87 10:44 EST
From: Guy Steele <gls@Think.COM>
Subject: FORMAT-OP-C
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870223200820.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870224104409.4.GLS@BOETHIUS.THINK.COM>
I favor KMP's proposal for ~C, as amended by Moon. --Guy
∂24-Feb-87 0744 gls@Think.COM PRINC-CHARACTER
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 24 Feb 87 07:44:16 PST
Received: from boethius by Think.COM via CHAOS; Tue, 24 Feb 87 10:43:37 EST
Date: Tue, 24 Feb 87 10:45 EST
From: Guy Steele <gls@Think.COM>
Subject: PRINC-CHARACTER
To: CL-Cleanup@sail.stanford.edu
Cc: gls@Think.COM
In-Reply-To: <870223222057.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870224104522.5.GLS@BOETHIUS.THINK.COM>
I favor PRINC behaving as WRITE-CHAR on character objects.
I believe that that is closest in spirit to the historical
behavior of PRINC on such character-like objects as 'A
and '| |.
--Guy
∂25-Feb-87 2007 Moon@STONY-BROOK.SCRC.Symbolics.COM Rob's Compiler Cleanup Proposal
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Feb 87 20:07:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79236; Wed 25-Feb-87 23:07:25 EST
Date: Wed, 25 Feb 87 23:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Rob's Compiler Cleanup Proposal
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12281173600.BABYL@C.CS.CMU.EDU>
Message-ID: <870225230554.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I can't say that I have understood absolutely everything in this
proposal yet, but on the whole it looks very clean and well thought
out. I agree that it should be widely circulated and discussed.
Here are some initial comments from myself and others at Symbolics;
there will undoubtedly be more later.
"It is an error to destructively modify any part of a Lisp data structure that
has been promoted to a program."
Does this mean that it is illegal to do things like
(DEFVAR *FOO* '(1 2 3))
(SETF (CDR *FOO*) NIL)
(SETQ A '(1 3 4))
(SETF (SECOND A) 2)
even when interacting with the read-eval-print loop? This needs to be
more clearly defined. Also, if users have to copy any quoted data structures
they plan to modify, Common Lisp's lack of a really general copying primitive
(for good reasons, defining the semantics is hard) becomes more glaring.
"When the system promotes a data structure to a program, it may
non-destructively replace any part of the program with any structurally
equivalent data structure that is known to be unmodifiable."
How can you "non-destructively replace" something? I think I know
what this means but it should be stated more clearly. And if there are
good reasons to forbid destructive replacement they should be clearly
stated too.
The warning inhibition stuff (Brevity optimize quality) seems overly
simplified. There may really be more than one kind of warning, to be
separately controlled, and more thought should be given to why warnings
are printed and what the user might do with them. Similar considerations
to the new tighter specification of the other optimize qualities. These
seem like good ideas but need some refinement, or maybe a period of
experimentation, before casting them in concrete as a standard.
The Compile-File Reference model:
"Implementations are encouraged to use a clean Compile-File environment
containing no user definitions. This implies that a Common Lisp program must
explicitly establish any definitions required in the compiler environment; this
is what the header forms in a code file are for."
It needs to be clear how you load a file (e.g. of macro definitions) into the
compiler environment, rather than having to compile it even if it hasn't changed.
An important deficiency of Common Lisp not addressed by this proposal is that
the internal mechanisms that keep track of these environments have not been made
accessible to the user. Everyone who has tried to implement a portable object
oriented programming system has run into this, for example. Of the various ways
to do this that I've seen, I (Moon) like this one the best:
(GET-BINDING name type env &optional default) returns the "binding" of <name>
in the <type> namespace in the environment defined by <env>, or if there isn't
a binding it returns <default>. SETF of GET-BINDING is allowed. There may need
to be a REMOVE-BINDING also, I'm not sure. <name> is usually a symbol but at
least in some systems other names are possible; anything that can be compared
with EQUAL should be allowed. <type> is usually a symbol and is the mechanism
for extensibility -- when you need a new namespace, you make a new type.
<env> is a lexical environment of the type received by macros in their
&environment argument. It encodes such information as whether we are in
the run-time environment or the compiler environment, and controls whether
and how the compiler environment inherits information from the run-time
environment if it didn't come from the file(s) being compiled. This is
dependent on the philosophy of the particular programming environment, so,
as with macros, the only portable operations on <env> are to receive it from
the system, hand it back to the system, and use NIL to mean the global
run-time environment.
So what's a "binding"? It's just an association of any value with a name.
The semantics depend on the type. Standardized type symbols for the built-in
namespaces should be defined, for instance for functions, but some thought is
needed because when the compiler compiles a function, the "binding" it remembers
for the compilation environment may not be an actual applicable function, but
some other data structure that represents the function's arguments, values,
and side-effects (if known).
What are user-defined types used for? Well, in object-oriented programming
types are needed for classes, generic operations, and methods. Any facility
or embedded language that needs to convey information from one top level form
to another, within a compilation, without clobbering the run-time environment,
would use get-binding as a repository for its data.
The resemblance to property lists is quite intentional. I'm not sure whether
implementations should be permitted to implement the null environment as
regular property lists, or whether this facility should be required to be
disjoint from property lists. I -am- sure that implementations should not be
required to implement the null environment as property lists.
Obviously this GET-BINDING proposal is not yet complete, the above is just
a general preview of what it would look like. I have no attachment to the
name, either. (In our system we have something similar called SYS:GETDECL,
which I think is an even worse name.) This proposal is obviously closely
related to others, such as the proposal to add an optional <env> argument
to get-setf-method.
∂25-Feb-87 2247 RPG [Andy Freeman <andy@shasta.stanford.edu>:]
∂23-Feb-87 1529 ANDY@Sushi.Stanford.EDU [Andy Freeman <andy@shasta.stanford.edu>:]
Received: from SUSHI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Feb 87 15:29:37 PST
Date: Mon 23 Feb 87 15:27:24-PST
From: Andy Freeman <ANDY@Sushi.Stanford.EDU>
Subject: [Andy Freeman <andy@shasta.stanford.edu>:]
To: rpg@Sail.Stanford.EDU
Message-ID: <12281440466.59.ANDY@Sushi.Stanford.EDU>
I don't know if you ever saw this but ....
-andy
---------------
Return-Path: <andy@shasta.stanford.edu>
Received: from shasta.stanford.edu by Sushi.Stanford.EDU with TCP; Mon 23 Feb 87 15:25:30-PST
Received: by shasta.stanford.edu; Mon, 23 Feb 87 15:27:50 PST
Date: Mon, 23 Feb 87 15:27:50 PST
From: Andy Freeman <andy@shasta.stanford.edu>
To: andy@sushi.stanford.edu
From labrea!decwrl!decvax!ucbvax!ucbcad!ames!rutgers!seismo!rochester!pt.cs.cmu.edu!spice.cs.cmu.edu!ram Mon Feb 23 15:16:09 PST 1987
Article 146 of comp.lang.lisp:
Path: Shasta!labrea!decwrl!decvax!ucbvax!ucbcad!ames!rutgers!seismo!rochester!pt.cs.cmu.edu!spice.cs.cmu.edu!ram
>From: ram@spice.cs.cmu.edu (Rob MacLachlan)
Newsgroups: comp.lang.lisp
Subject: Re: Against the Tide of Common LISP
Message-ID: <1144@spice.cs.cmu.edu>
Date: 23 Feb 87 11:54:47 GMT
References: <2624@well.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 53
I found this highly relevant document about the Common Lisp design process
while cleaning my directory. It was written by Skef Wholey, who implemented
a large part of Spice Lisp while a full-time undergraduate student. The
Common Lisp spec was being developed at the same time that Spice Lisp was
being written. This was a cause for no little aggravation for Skef, since he
often had to rewrite code several times.
________________________________________________
Common LISP
(to the tune of Dylan's "Maggie's Farm")
I ain't gonna hack on Common LISP no more,
I ain't gonna hack on Common LISP no more.
See, it was spawned from MACLISP,
And then they threw in Scheme,
And now everybody's made it
"just a little" short of clean.
The language specification is insane.
I ain't gonna hack on Guy Steele's LISP no more,
I ain't gonna hack on Guy Steele's LISP no more.
When you mail him a question,
And then wait for a reply,
Well you can sit for weeks now,
And begin to think he's died.
His MAIL.TXT is one great big black hole.
I ain't gonna hack on Fahlman's LISP no more,
I ain't gonna hack on Fahlman's LISP no more.
Well he gives you an X-1,
And he puts you on a Perq,
And he asks you with a grin,
"Hey son, how much can you work?"
If I reboot one more time I'll lose my brain.
I ain't gonna hack on Dave Moon's LISP no more,
I ain't gonna hack on Dave Moon's LISP no more.
We had a simple SETF,
But it choked on LDB.
So Lunar Dave done fixed it:
Go look at page eighty three.
The Gang of Five they didn't take a poll.
I ain't gonna hack on Common LISP no more,
I ain't gonna hack on Common LISP no more.
With its tons of sequence functions,
And its lexical scoping,
I've now begun to like it,
But the users are moping:
"Without EXPLODE my life is full of pain."
(harmonica and fade)
-------
∂26-Feb-87 0104 RAM@C.CS.CMU.EDU Rob's Compiler Cleanup Proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Feb 87 01:04:34 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 26 Feb 87 04:05:20-EST
Date: Thu, 26 Feb 1987 04:05 EST
Message-ID: <RAM.12282069950.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Rob's Compiler Cleanup Proposal
In-reply-to: Msg of 25 Feb 1987 23:05-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Date: Wednesday, 25 February 1987 23:05-EST
From: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
To: cl-cleanup at SAIL.STANFORD.EDU
Re: Rob's Compiler Cleanup Proposal
Does this mean that it is illegal to do things like
(DEFVAR *FOO* '(1 2 3))
(SETF (CDR *FOO*) NIL)
(SETQ A '(1 3 4))
(SETF (SECOND A) 2)
even when interacting with the read-eval-print loop?
I would say that it would be legal for an implementation to bum out
when you do this, but users might reasonably consider this to be
unreasonable behavior. There currently is a note about it being
unreasonable for the system do strange things to constants typed in at
top level. Perhaps this should be expanded on in a discussion of
top-level philosophy, but I don't think this is really very important
for the standard, since people will be porting programs rather than
transcripts of top-level sessions.
"When the system promotes a data structure to a program, it may
non-destructively replace any part of the program with any structurally
equivalent data structure that is known to be unmodifiable."
How can you "non-destructively replace" something? I think I know
what this means but it should be stated more clearly. And if there are
good reasons to forbid destructive replacement they should be clearly
stated too.
Well, I think it would pretty strange for EVAL to destructively modify
its argument. I guess "non-destructive replace any part" means that
the system is free to do something equivalent to building a new
structurally equivalent form that may contain old structures as parts.
The warning inhibition stuff (Brevity optimize quality) seems overly
simplified. There may really be more than one kind of warning, to be
separately controlled, and more thought should be given to why warnings
are printed and what the user might do with them.
Well, it seems to me that it allows for four kinds of warnings, since
it can be traded off against any of the other optimize qualities.
Although existing compilers may tend to have individual switches that
control particular warnings, I suspect that a Brevity proclamation
could do a pretty good job of controlling all of these switches
simultaneously. There is nothing that prevents an implementation from
providing some mechanism for finer control over warnings. There are
three reasons for putting Brevity in the spec:
1] It encourages implementors to think about providing good,
controllable diagnostics.
2] It gives users a useful level of control without requiring them to
understand 50 implementation dependent switches.
3] Brevity = 3 guarantees that reasonable programs can be compiled on
any system without warnings.
Similar considerations
to the new tighter specification of the other optimize qualities. These
seem like good ideas but need some refinement, or maybe a period of
experimentation, before casting them in concrete as a standard.
I'm not sure what you want clarified here, but I feel pretty strongly
about the discussions of safety and correctness.
It seems to me to be obviously true that no legal optimize declaration
should cause to cause a legal program to stop working. I chose the
particular examples of illegal "optimizations" because they are things
I have known compilers to do that are contrary to Common Lisp
semantics. If it is prohibitive to disallow these "optimizations"
then we should change Common Lisp semantics rather than making the
semantics of evaluation undefined.
Although my suggestion for the interpretation of type declarations and
the Safety quality is at odds with current practice, it is also
"obvious" to me that safety is a policy issue and declarations have
semantics, and the two shouldn't be confused. The discussion of
safety is just a guideline for implementors, since implementations
aren't required to be safe.
The Compile-File Reference model:
"Implementations are encouraged to use a clean Compile-File
environment containing no user definitions. This implies that a
Common Lisp program must explicitly establish any definitions
required in the compiler environment; this is what the header
forms in a code file are for."
It needs to be clear how you load a file (e.g. of macro
definitions) into the compiler environment, rather than having to
compile it even if it hasn't changed.
Well, the only way to load something in the header forms is to use
Require. It would also be possible to say:
(early-eval-only (load "macros"))
An important deficiency of Common Lisp not addressed by this
proposal is that the internal mechanisms that keep track of these
environments have not been made accessible to the user. Everyone
who has tried to implement a portable object oriented programming
system has run into this, for example.
I was hoping to make an end run around this entire issue. I don't
know how clear this in the proposal, but the idea is that except for
the potential separation of the Compile-File environment, there is
only the normal Lisp environment. Furthermore, the Lisp environment
seen by code run during early evaluation in Compile-File is the exact
same environment that Compile-File places early evaluated definitions
in. It is totally legal to say:
(defmacro foo () ...)
(early-eval (print (foo)))
That is, compiling a Defmacro or a Deftype or whetever clobbers the
current definition in the Lisp that the early evaluation is done in.
Implementations will presumably have some "bootstrap" switch that they
throw so that they can compile the compiler or whatever, but I would
rather not attempt to standardize this sort of thing.
I think that Lisp implementors have an exaggerated impression of the
importance of such features, since they spend all their time working
on the system code that has these bootstrapping difficulties. Normal
users are only confused by the kludgey "separate compiler
environments" that existing systems have.
I would be much more confident of coming up with a clean specification
for a compiler environment if Common Lisp had first-class
environments. Compilers that I know of only special-case a few kinds
of definitions such as macros and structures, and these "compiler
environment" definitions are not visible to macros and other code that
runs in the compiler. I think that the compiler environment issue is
a semantic quagmire, and I would very much like to ignore it.
It would seem that portable system programs (such as object systems)
are the only thing that would really benefit from having some sort of
standardized environment interaction facilities. Since such systems
tend to need various hooks into the guts of the system anyway, I'm not
convinced that this is a major issue.
Also, it is the intention that it would be legal for Compile-File to
create a separate heavy-weight process and shove the files to it. If
we allow this, then we can't reqire any interesting communication
between the "compiler environment" and the "normal Lisp environment".
Rob
∂26-Feb-87 1504 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
Proposal: FUNCTION-TYPE
References: functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
APPLY (pg 107).
Category: CHANGE/CLARIFICATION
Edit History: Revision 1 by RPG 02/26/87
Problem Description:
The definition of the term `function' in CLtL includes all symbols
and many lists in addition to true functions. The type named `FUNCTION'
is, therefore, not a reasonable type. The language would be much cleaned up
and improved if functions were treated as a type in a consistent and useful
manner. Most of the reason for the current state of affairs is the desire
for compatability with the past.
Proposal:
Page 32, section 2.13 should be amended to read:
``A *function* is anything that might be correctly given to the FUNCALL or APPLY
function and is to be executed as code when arguments are supplied.
``The result of evaluating a FUNCTION special form will always be a function.''
Page 33, section 2.15: the third bulleted item should be amended to
read:
``* The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are
pairwise disjoint.''
Page 76, the description of FUNCTIONP should be amended to read:
``FUNCTIONP is true if its argument is a function (see page 32).''
Page 107, the second sentence should be amended to read:
``*Function* must be a function (see page 32).''
Page 107, the first and fourth examples should be amended to read:
(setq f #'+) (apply f '(1 2)) => 3
(apply #'cons '((+ 2 3) 4)) =>
((+ 2 3) . 4) *not* (5 . 4)
Other examples might require amendment.
Rationale:
I believe that this change takes a currently meaningless concept in Common
Lisp (a function) and gives it a firmer foundation. Many programmers
cannot rely on FUNCTIONP filtering out true functions from mere symbols.
Current Practice:
Programmers write their own predicate for true FUNCTIONP.
Adoption Cost:
Compiled functions are true functions in almost all implementations, but,
in some implementations, interpreted functions are represented as lists.
This would need to be changed in the interpreter, FUNCALL, APPLY, and
other places.
Benefits:
A concept would be resurrected: currently the concept of a function in
Common Lisp is bankrupt. Common Lisp would come in closer alignment with
Scheme. It is the first step towards a Lisp1-ification of Common Lisp.
Conversion Cost:
Unknown. Deep-rooted bugs could be uncovered.
Aesthetics:
Making the concept of a function well-defined will probably be perceived
as a simplification.
Discussion:
RPG and Will Clinger believe it is important to get this cleared up as
soon as possible.
∂26-Feb-87 1944 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 26 Feb 87 19:44:12 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80144; Thu 26-Feb-87 22:44:11 EST
Date: Thu, 26 Feb 87 22:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870226224313.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: IGNORE-ERRORS
References: p428
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/26/87
Problem Description:
Common Lisp has no way to trap an error inhibiting entry to the debugger.
Proposal (IGNORE-ERRORS:INTERIM):
Remove the apology for the absence of ERRSET on p428 and introduce
mention of a new macro called IGNORE-ERRORS with the syntax
(IGNORE-ERRORS {form}*)
Say that it attempts to execute the given forms in order from left to right,
returning all the values returned by the last form (or NIL if there
are no forms). If an error occurs while executing the forms, no error
message is printed; instead control is silently transfered to the
IGNORE-ERRORS form, which immediately returns NIL.
Rationale:
It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next CL spec.
The baroque return value convention used by Maclisp's ERRSET special form
(mentioned on p428 of CLtL) does not extend gracefully to situations multiple
values.
Current Practice:
Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.
Adoption Cost:
As far as I know, this would not be difficult to implement in any implementation.
eg, IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS)
(LET ((TAG (GENSYM)))
`(BLOCK ,TAG
(ERRSET (RETURN (PROGN ,@FORMS)) NIL)
NIL)))
Benefits:
An error proposal is in the works which will offer IGNORE-ERRORS and more.
In case of delays or problems in the acceptance of the spec, applications
developers will not have to worry that they'll end up with no way to trap
errors.
Conversion Cost:
User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.
Aesthetics:
This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
∂26-Feb-87 1945 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 26 Feb 87 19:45:38 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80145; Thu 26-Feb-87 22:45:58 EST
Date: Thu, 26 Feb 87 22:45 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (revision 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Supersedes: <870226224313.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870226224504.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: IGNORE-ERRORS
References: p428
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/26/87,
Revision 2 by KMP 02/26/87 (fixed typo in sample code)
Problem Description:
Common Lisp has no way to trap an error inhibiting entry to the debugger.
Proposal (IGNORE-ERRORS:INTERIM):
Remove the apology for the absence of ERRSET on p428 and introduce
mention of a new macro called IGNORE-ERRORS with the syntax
(IGNORE-ERRORS {form}*)
Say that it attempts to execute the given forms in order from left to right,
returning all the values returned by the last form (or NIL if there
are no forms). If an error occurs while executing the forms, no error
message is printed; instead control is silently transfered to the
IGNORE-ERRORS form, which immediately returns NIL.
Rationale:
It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next CL spec.
The baroque return value convention used by Maclisp's ERRSET special form
(mentioned on p428 of CLtL) does not extend gracefully to situations multiple
values.
Current Practice:
Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.
Adoption Cost:
As far as I know, this would not be difficult to implement in any implementation.
eg, IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS)
(LET ((TAG (GENSYM)))
`(BLOCK ,TAG
(ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
NIL)))
Benefits:
An error proposal is in the works which will offer IGNORE-ERRORS and more.
In case of delays or problems in the acceptance of the spec, applications
developers will not have to worry that they'll end up with no way to trap
errors.
Conversion Cost:
User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.
Aesthetics:
This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
∂26-Feb-87 2004 KMP@STONY-BROOK.SCRC.Symbolics.COM DEFVAR-INITIALIZATION
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 26 Feb 87 20:04:30 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80162; Thu 26-Feb-87 23:04:48 EST
Date: Thu, 26 Feb 87 23:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFVAR-INITIALIZATION
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870226230353.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Proposal: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/26/87
Problem Description:
The description of DEFVAR on p68 is not adequately clear on what happens
if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
I think that most implementations already do not initialize the variable.
Some implementations, however, assume that the missing initial value
defaults to NIL and assume that the variable is always to be initialized
if unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change.
In fact, most people would probably agree that it's stylistically poor
to be relying on the variable to be initialized without writing the initial
value explicitly anyway. Except for very rare situations where a
conditional action is taken based on a BOUNDP test of the variable, user
programs are unlikely to be affected in practice.
The modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to declare a variable without
initializing it. More importantly, though, DEFVAR is used by lots of users
in every implementation and it deserves uniform treatment.
Conversion Cost:
Very few user programs are likely to be affected. The incidence rate is probably
sufficiently low that the issue of automatic tools for conversion is irrelevant.
Aesthetics:
No significant issues are obvious to me.
Discussion:
KMP supports this change.
∂27-Feb-87 0855 sandra%utah-orion@utah-cs.arpa What does this bit of code do?
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 08:55:33 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA23127; Fri, 27 Feb 87 09:57:41 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA06791; Fri, 27 Feb 87 09:57:38 MST
Date: Fri, 27 Feb 87 09:57:38 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8702271657.AA06791@utah-orion.ARPA>
Subject: What does this bit of code do?
To: common-lisp@sail.stanford.edu
Suppose I define function "foo" like so:
(defun foo
(unwind-protect
(throw 'silly t)
(return-from foo nil)))
What does (catch 'silly (foo)) return?
-Sandra
-------
∂27-Feb-87 0916 gls@Think.COM What does this bit of code do?
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Feb 87 09:16:04 PST
Received: from boethius by Think.COM via CHAOS; Fri, 27 Feb 87 12:15:24 EST
Date: Fri, 27 Feb 87 12:17 EST
From: Guy Steele <gls@Think.COM>
Subject: What does this bit of code do?
To: sandra%utah-orion@utah-cs.arpa, common-lisp@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <8702271657.AA06791@utah-orion.ARPA>
Message-Id: <870227121710.5.GLS@BOETHIUS.THINK.COM>
Date: Fri, 27 Feb 87 09:57:38 MST
From: sandra%utah-orion@UTAH-CS.ARPA (Sandra J Loosemore)
Suppose I define function "foo" like so:
(defun foo
(unwind-protect
(throw 'silly t)
(return-from foo nil)))
What does (catch 'silly (foo)) return?
-Sandra
-------
I say it should return nil. (I assume that you meant to
have an empty argument list following "defun foo", as otherwise
the function would have a null body, parameters named UNWIND-PROTECT,
THROW, and RETURN-FROM, and supplied-p parameters named T and NIL.)
--Guy
∂27-Feb-87 0934 gls@Think.COM FUNCTION-TYPE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Feb 87 09:34:09 PST
Received: from boethius by Think.COM via CHAOS; Fri, 27 Feb 87 11:55:10 EST
Date: Fri, 27 Feb 87 11:56 EST
From: Guy Steele <gls@Think.COM>
Subject: FUNCTION-TYPE
To: RPG@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <8702262305.AA22492@Think.COM>
Message-Id: <870227115655.4.GLS@BOETHIUS.THINK.COM>
I favor the FUNCTION-TYPE proposal, with some mild reservations
because I think the proposal underemphasized the costs of conversion.
Nevertheless I would support this proposal befroe the committee,
because the current state of affairs is confusing.
--Guy
∂27-Feb-87 1018 KMP@STONY-BROOK.SCRC.Symbolics.COM What does this bit of code do?
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 10:17:33 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80505; Fri 27-Feb-87 13:15:51 EST
Date: Fri, 27 Feb 87 13:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: What does this bit of code do?
To: gls@Think.COM
cc: sandra%utah-orion@utah-cs.arpa, common-lisp@sail.stanford.edu
In-Reply-To: <870227121710.5.GLS@BOETHIUS.THINK.COM>
Message-ID: <870227131457.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I happen to agree with you, but it is a point more controversy than I
would have expected. We had a lot of discussion about it internally at
Symbolics a while back. In any case, nailing down the semantics of
non-local exit from UNWIND-PROTECT is on my list of changes to submit
to the cleanup committee in the very near future. (To those not on
that committee, don't panic -- we don't actually make any decisions,
we just package up the space of options into ballot items that can be
voted upon by X3J13.)
∂27-Feb-87 1423 KMP@STONY-BROOK.SCRC.Symbolics.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 14:22:53 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 80817; Fri 27-Feb-87 17:22:48 EST
Date: Fri, 27 Feb 87 17:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870227172152.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
References: UNWIND-PROTECT (p140, p142, p39)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Problem Description:
If a non-local return is done while in the cleanup form of an
UNWIND-PROTECT, the behavior is not always well-defined.
There are three basic cases:
0. Transfer to another point within the cleanup form.
(UNWIND-PROTECT 3 (BLOCK NIL (RETURN 4)) (PRINT 'XXX))
I believe that we all agree about how this form is to
be interpreted. Effectively:
. 3 evaluates to itself, which is queued for return
from the UNWIND-PROTECT.
. The BLOCK expression is entered, 4 is returned to
it and discarded because this is a not-for-value
situation.
. XXX is printed, XXX is returned by the PRINT and
that value is discarded because this is a not-for-value
situation.
. The 3 which was yielded earlier is retrieved and
returned as the value of the UNWIND-PROTECT.
1. Transfer to a point inside the point to which control
would have transferred.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
I believe that this is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found within the scope of the target of the
pending THROW (to FOO).
2. Transfer to a point outside the point to which return would
already have been. For example:
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
I believe that this is a subject of controversy because:
. 3 evaluates to itself and is saved by THROW which begins
searching for tag FOO.
. 4 evaluates to iself and is saved by THROW which begins
searching for tag BAR.
. Disagreement exists as to whether it is an error if the
BAR tag is not found within the local dynamic scope of
the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
but is found outside the scope of the target of the
pending THROW (to FOO).
Note about Voting:
Two votes are required here: a behavior for item 1 and a
behavior for item 2.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1A):
Some may believe that what this code is doing is an error,
and that the debugger should be entered with (PRINT 'XXX)
still pending for execution after exit from the debugger.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1B):
Some may believe that what this code is doing is an error,
and that the debugger should be entered but the (PRINT 'XXX)
would not be executed upon exit from the debugger.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1C):
Others may believe that the pending seek for tag FOO is
discarded by the second THROW and that value 4 is transfered
to (CATCH 'BAR ...), which returns 4.
The (CATCH 'FOO ...) then returns the 4 because it's first
argument has returned normally.]
Of course, it follows that XXX is not printed in this case.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1D):
Some may believe that after the throw to BAR is done, the
THROW to FOO should somehow complete but that XXX would
never be printed.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1E):
Some may believe that after the throw to BAR is done, the
THROW to FOO should somehow complete and that XXX would be
printed.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:2A):
Some may believe that what this code is doing is an error,
and that the debugger should be entered with (PRINT 'XXX)
still pending for execution after exit from the debugger.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:2B):
Some may believe that what this code is doing is an error,
and that the debugger should be entered but the (PRINT 'XXX)
would not be executed upon exit from the debugger.
Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:2C):
Others may believe that the pending seek for tag FOO is
discarded by the second THROW and that value 4 is transfered
to (CATCH 'BAR ...), which returns 4.
Of course, it follows that XXX is not printed in this case.
Rationale (C):
I can only supply rationales for 1C and 2C because they are
the only ones I understand. In Scheme, the action of THROW
is usefully described by saying that it is just like any
other function. It happens to discard the current continuation,
run some cleanup things (like variable unbindings and
UNWIND-PROTECT actions), and transfer control elsewhere in
the program. In doing so, the function uses data structure
primitives not generally available to other programs, but it
is not linguistically different and receives no special
exemption with regard to THROWs or other non-local transfers
of control done within its execution.
As such, a THROW from within an UNWIND-PROTECT cleanup
is not different than one in any other code. It discards the
ongoing action (stack unwinding) and replaces it by another
action (as it happens, another stack unwinding). The previous
unwind is never resumed.
Current Practice:
Most interpreted implementations agree with implementation
1C and 2C.
Some compiled implementations agree with 1C and 2C.
Some just output garbage code (probably because lots of people
don't anticipate this case, which is admittedly quite rare).
There may be implementations which do not take action C.
Certainly I have heard such be seriously proposed by competent
professionals.
Adoption Cost:
In most cases, correctly supporting any solution we pick up
will require some compiler modification. In some (perhaps many)
cases, that work was in order anyway since compilers may
currently be doing nothing particularly useful or defensible with
the code in question.
Benefits:
Programs which do this accidentally should behave the same on
all systems so that bugs can be detected and fixed very early
rather than being found later on a system which disagrees.
Programs which do this on purpose generally are trying to do
something fairly intricate and really need to be able to depend
on it being uniformly treated. A portable error system and
debugger may be among these.
Conversion Cost:
Most user programs don't do this so the cost of converting
existing code is probably minimal. (I would bet that anyone
who is deliberately doing this already is expecting option C
anyway, so the cost of conversion is even lower in that case.)
Aesthetics:
Languages are always easier to understand if the semantics of
primitive linguistic glue is well-defined. In that regard,
anything is better than the current state.
Option C is likely to be a lot more intuitive to Scheme
programmers and people who do reasoning about programs in
terms of continuation passing than any of the other options.
Discussion:
Obviously, the same arguments relate to other kinds of non-local
return (whether lexical or dynamic in nature) across the same
boundaries. Equivalent arguments can be given for the behavior of
RETURN, RETURN-FROM, GO, etc. In the lexical case, the nature of
the search is somewhat different both in time (early binding)
and technique, but for the sake of this discussion that distinction
is not important to me. If someone believes that it is, they should
say so. For now, this vote should be assumed to implicitly address
all such primitives so that they are treated consistently and so
that no later redundant votes on this messy issue are necessary.
KMP strongly favors options 1C and 2C.
∂27-Feb-87 1518 KMP@YUKON.SCRC.Symbolics.COM COMPILER-WARNING-STREAM
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 15:18:02 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 171021; Fri 27-Feb-87 18:11:28 EST
Date: Fri, 27 Feb 87 18:10 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPILER-WARNING-STREAM
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870227181032.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does
not permit them to print warnings. If this is to be allowed,
it should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
The definitions of COMPILE and COMPILE-FILE should state that
these functions are permitted to output warnings and that those
warnings should go to the stream which is the value of
*ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation.
Warnings that come via the WARN function will go to the stream
which is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send warning output to *ERROR-OUTPUT*.
Other implementations send warning output to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is
expected to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE
and COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of
both situations or naively expect that output will go to
*ERROR-OUTPUT*. As such, most users will probably perceive this
as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN
and the kind of warning that comes from compilation to be
conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because
Macsyma provides alternate user interfaces to the compiler which
it needs to be able to control.
KMP supports this change.
∂27-Feb-87 1521 KMP@YUKON.SCRC.Symbolics.COM COMPILER-WARNING-BREAK
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 15:21:30 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 171028; Fri 27-Feb-87 18:21:17 EST
Date: Fri, 27 Feb 87 18:21 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPILER-WARNING-BREAK
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870227182114.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does
not say whether *BREAK-ON-WARNINGS* affects warnings output
by the compiler. If this is to be allowed, it should be an
explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that
these functions are required to break on warnings if
*BREAK-ON-WARNINGS* is true (just as occurs for calls to WARN).
Note: User interface commands provided by particular vendor
implementations which implicitly call COMPILE or COMPILE-FILE
could bind *BREAK-ON-WARNINGS* back to NIL if they felt it
important to not break for some reason relating to cultural
compatibility. This would not interfere with the proposed new
semantics for the functions COMPILE and COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be
entered when warnings occur. If the compiler is permitted to
warn (separate ballot item), the effect of this variable on
compiler warnings should be nailed down.
Current Practice:
I would guess that some compilers respect *BREAK-ON-WARNINGS*
and others probably do not.
Adoption Cost:
I assume this is easy to arrange for in all implementations.
Benefits:
This would make the language definition more consistent by
making it less subject to special cases.
Conversion Cost:
Probably little or no user code would be affected by this
change.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN
and the kind of warning that comes from compilation to be
conceptually grouped.
Discussion:
KMP supports this change.
∂27-Feb-87 1557 KMP@YUKON.SCRC.Symbolics.COM IF-BODY
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 15:56:52 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 171034; Fri 27-Feb-87 18:41:30 EST
Date: Fri, 27 Feb 87 18:41 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870227184126.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/27/87
Problem Description:
IF only allows 2 or 3 arguments.
Because CLtL specifies that upward compatible extensions are permissible
when they don't interfere with the language semantics, many implementations
have provided an extended syntax for IF that looks like:
(IF test then {else}*)
The problem is that systems providing this extension do not provide
error checks that tell developers of code that will be ported when they're
likely to lose.
As such, this is a source of frustration for users, only a small fraction of
which care about arguing about whether more than three arguments is aesthetic.
They just want their programs to port without hassle. CLtL has egged on the
problem by explicitly suggesting that such extensions were permissible.
Proposal (IF-BODY:YES):
We should extend IF to accept a body of else forms (to be treated as an
implicit PROGN).
Rationale:
Since we are unlikely to agree that more than 3 arguments must signal an
error in all implementations, we should agree on this solution which leaves
the question of aesthetics up to the individual programmer.
Current Practice:
Some implementations already provide this feature.
Many others could trivially add it.
A few may provide alternate keyword-driven extensions to IF that are
incompatible with this extension.
Adoption Cost:
Presumably most implementations would require minor adjustments to the
interpreter, the compiler, and any code walking tools.
Benefits:
This will greatly diminish a common source of aggravation in many customer
applications.
Conversion Cost:
Most user code which simply uses IF would not be affected adversely
except in implementations which provided keyword-driven extensions.
In such implementations, it would probably be possible to provide
tools to at least search for problemsome cases if not also to automatically
convert them.
Some user-defined code may be depending on understanding the syntax of
IF because it is defined to be a primitive special form. Such programs
would be broken, though fixing them would not be complicated and the
fixes would generally be upward-compatible with the existing semantics.
Aesthetics:
Some people like the IF body idea and find it more visually aesthetic
than the more-parenthesized (and incidentally also more-indented)
COND alternative.
Some people really dislike the idea of an IF body.
Except for those who write program-manipulating programs, though, no one
is being forced to change their personal programming style.
Discussion:
KMP thinks this very middle of the road on the aesthetic issue and
thinks that this change would be valuable for purely pragmatic reasons.
∂27-Feb-87 1607 KMP@YUKON.SCRC.Symbolics.COM FORMAT-ATSIGN-COLON
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 16:06:54 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 171046; Fri 27-Feb-87 18:59:41 EST
Date: Fri, 27 Feb 87 18:59 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-ATSIGN-COLON
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870227185938.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FORMAT-ATSIGN-COLON
References: FORMAT description (p386)
Category: CLARIFICATION
Edit history: Revision 1 by KMP 02/27/87
Problem Description:
The manual describes the format op syntax as:
``a format directive consists of a tilde (~), optional prefix
parameters separated by commas, optional colon (:) and
at-sign (@) modifiers, and a single character indicating
what kind of directive this is.''
The manual uses :@ fairly consistently throughout without
saying whether @: is legal.
Proposal (FORMAT-ATSIGN-COLON:OK):
The manual should state that there is no required ordering
between the @ and : modifier.
Rationale:
Internally, this is the only rational thing since most implementations
represent only present-p and not ordering information about the atsign
and colon modifiers in their definitions of format ops.
Current Practice:
Most implementations accept these in either order.
Some implementations have been known to expect only :@.
Adoption Cost:
The change to accept either syntax is probably quite trivial.
Benefits:
Having @: and :@ mean different things would be awkward.
Having one of the two be illegal would be gratuitously painful.
Conversion Cost:
Existing code is pretty much unaffected.
Aesthetics:
Leaving these unordered is probably slightly simpler conceptually.
Discussion:
KMP thinks this is worth doing.
∂27-Feb-87 1651 KMP@YUKON.SCRC.Symbolics.COM SHARPSIGN-BACKSLASH-BITS
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 27 Feb 87 16:51:39 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 171066; Fri 27-Feb-87 19:51:29 EST
Date: Fri, 27 Feb 87 19:51 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-BACKSLASH-BITS
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870227195124.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SHARPSIGN-BACKSLASH-BITS
References: #\ (p354)
Category: CLARIFICATION
Edit history: Revision 1 by KMP 02/27/87
Problem Description:
The description of names for characters that has bits gives examples without
clearly specifying the meaning of the bit names.
Proposal (SHARPSIGN-BACKSLASH-BITS:SHORT-AND-LONG):
It should be clearly stated at the appropriate point (currently on p354)
that the names "C" and "CONTROL" mean control, "M" and "META" mean meta,
"S" and "SUPER" mean "SUPER", and "H" and "HYPER" mean hyper. It should
further specified that these can be mixed and matched, as in "C-META-X".
Rationale:
We give examples of both styles, so both styles should be well-defined.
If these are not going to be well-defined, there's no point in our giving
examples of them.
Current Practice:
Most implementations support both short and long names to back up the bit
names that they allow.
Some implementations accept only the short name. Others only the long name.
Adoption Cost:
The cost of this change is very small.
Benefits:
If an input syntax is going to reliably exist, we need to say so.
Conversion Cost:
User code is not likely to be adversely affected. Most users will likely
perceive this as a bug fix.
Aesthetics:
This doesn't much affect aesthetics one way or the other.
Discussion:
KMP thinks this is a good idea.
∂28-Feb-87 1835 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 18:35:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 28 Feb 87 21:36:25-EST
Date: Sat, 28 Feb 1987 21:36 EST
Message-ID: <FAHLMAN.12282785586.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE
In-reply-to: Msg of 26 Feb 1987 18:04-EST from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
I think I see what RPG is suggesting, but I have a bunch of questions
about the details and implications of his proposal. I'll try to
organize my thoughts on this in the next couple of days and send out
something on this topic.
-- Scott
∂28-Feb-87 1841 FAHLMAN@C.CS.CMU.EDU IGNORE-ERRORS
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 18:41:11 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 28 Feb 87 21:41:57-EST
Date: Sat, 28 Feb 1987 21:41 EST
Message-ID: <FAHLMAN.12282786592.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: IGNORE-ERRORS
In-reply-to: Msg of 26 Feb 1987 22:43-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I agree with this proposal.
I'd like to believe that an error proposal is close enough that it could
be adopted at about the same time as the first batch of cleanup issues,
but KMP may know of problems that I don't see. In any event, it can't
hurt to go ahead and adopt this, especially if this same enhancement is
included in the error proposal so that there is no question of which
takes precedence.
-- Scott
∂28-Feb-87 1902 FAHLMAN@C.CS.CMU.EDU DEFVAR-INITIALIZATION
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 19:01:58 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 28 Feb 87 22:02:45-EST
Date: Sat, 28 Feb 1987 22:02 EST
Message-ID: <FAHLMAN.12282790380.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: DEFVAR-INITIALIZATION
In-reply-to: Msg of 26 Feb 1987 23:03-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support this proposal.
For what it may be worth, Spice Lisp has always implemented DEFVAR this
way, and KMP's "conservative" interpretation has always seemed the
obvious one to me. Still, if some implementations differ on this point,
that's evidence that a clarification is in order.
∂28-Feb-87 1910 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
The point of the proposal is to make the type named FUNCTION
have a more satisfying meaning. The Object System (CLOS - pronounced
``See-Loss'') cannot have a class for functions unless the Common
Lisp notion of a function is cleaned up.
Things that currently are functions that will no longer be functions
are symbols and lists of the form (lambda ...). If we like things
that look like (lambda ...) to be functions, we can make LAMBDA be a
special form that returns a function.
In many implementations, a coercion is replaced by a call to an
error-signaling routine in functions like APPLY and FUNCALL. I think
some interpreters, such as the Spice Lisp interpreter, will need to
be slightly re-worked. I'm not sure what other things are lurking in
the various implementations, so I cannot comment further on what other
things will need to be changed.
We can now write
(when (and (numberp x)(numberp y)) (+ x y))
knowing that the addition will happen exactly when x and y are
numbers and that there will be no errors signalled
This, on the other hand,
(when (functionp x) (funcall x))
has no such intuitive behavior.
Try these:
(setq x 'a)
(when (functionp x) (funcall x))
(setq x '(lambda 99 33))
(when (functionp x) (funcall x))
I think some implementators will have more difficulty than others in
making the change, and so I believe that a long ramp for this change is
necessary. I believe that there is now no reason to hang onto
compatability with MacLisp and ZetaLisp.
There is plenty of experience with there being a type comprising
true functions in the Scheme world.
-rpg-
∂28-Feb-87 1930 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 19:30:29 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 28 Feb 87 22:31:12-EST
Date: Sat, 28 Feb 1987 22:31 EST
Message-ID: <FAHLMAN.12282795558.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE
In-reply-to: Msg of 28 Feb 1987 22:10-EST from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Well, let me ask one question that is bothering me right away. I
understand why we might want to create a FUNCTION type that includes
compiled functions and what I would call interpreted closures, but that
excludes lists whose car is lambda and symbols that may or may not be
defined. (I have some other concerns about that, but will defer them
for now.)
However, I'm not sure it is necessary that this new FUNCTION type be
disjoint from the LIST type. In some systems the easy thing would be to
implement these closure-objects as a list with something special in the
CAR. Any good reason to outlaw this? (Sure, interpreters could use a
structure instead, but there might be efficiency reasons not to do
this.)
-- Scott
∂28-Feb-87 2050 FAHLMAN@C.CS.CMU.EDU UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 20:50:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 28 Feb 87 23:51:14-EST
Date: Sat, 28 Feb 1987 23:51 EST
Message-ID: <FAHLMAN.12282810128.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
In-reply-to: Msg of 27 Feb 1987 17:21-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
My preference would be 1A or 1B and 2A or 2B.
I don't think that KMP's distinction between the A and B cases is
useful, because I think it is totally meaningless to simply "exit from
the debugger" after an unseen-throw-tag error and proceed to execute the
code after the throw. Any halfway decent compiler would have decided
that this code is unreachable and would have thrown it away. (The same
is true for GO and any other unconditional transfer that fails.)
More precisely, I think we should specify that it "is an error" for the
cleanup forms of an unwind-protect to contain any non-local transfer of
control that exits that unwind-protect. I think that this is the best
solution precisely because it eliminates any confusion about which
non-local transfer should take precedence under what conditions.
If anyone can point out a situation in which such a non-local exit is
really useful (that is, it does something that is not easily
accomplished some other, less confusing way) then I agree with KMP that
1C and 2C is the most reasonable interpretation, and the one least
likely to contain further nasty interactions in complex cases we haven't
thought of yet. I could live with C.
Spice Lisp currently seems to do 1C and 2C, both compiled and
interpreted.
-- Scott
∂28-Feb-87 2115 FAHLMAN@C.CS.CMU.EDU COMPILER-WARNING-STREAM
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 21:15:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 1 Mar 87 00:15:54-EST
Date: Sun, 1 Mar 1987 00:15 EST
Message-ID: <FAHLMAN.12282814613.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: COMPILER-WARNING-STREAM
I agree with the proposal COMPILER-WARNING-STREAM:ERROR-OUTPUT.
I think that there's a misleading statement in the problem description
that should be repaired before the proposal goes out to the community.
The sentence "The description of the COMPILE and COMPILE-FILE functions
does not permit them to print warnings" is a bit too strong, I think.
I think it would be more correct to say, "The description of the COMPILE
and COMPILE-FILE functions does not say anything about where compiler
warnings may be printed."
(It has been suggested by KMP that no function may print anything to
*standard-output* unless the manual explicitly says it can. This has
not been extensively debated and may be controversial, so I don't want
to issue a statement that seems to imply that we accept this principle.)
∂28-Feb-87 2120 FAHLMAN@C.CS.CMU.EDU [RAM: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT]
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 21:20:18 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 1 Mar 87 00:21:02-EST
Date: Sun, 1 Mar 1987 00:20 EST
Message-ID: <FAHLMAN.12282815552.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: [RAM: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT]
I find the following arguments persuasive, so I would like to change my
position on this issue from favoring A/B to favoring proposal C, as KMP
does.
---------------------------------------------------------------------------
Date: Sunday, 1 March 1987 00:06-EST
From: Rob MacLachlan <RAM>
To: Scott E. Fahlman <Fahlman>
Re: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Although you may think that it is hairy to allow unwinding out of
cleanup forms, it complicates the language semantics more to disallow
it. It may be non-obvious that you can unwind in these places, but it
falls out of the normal scoping rules in a straightforward way once
you beat in the idea that the cleaup code is evaluated in the lexical
and dynamic environment in which the unwind-protect form appears.
Forbidding non-local exits makes evaluation in a cleanup form
different from evaluation anywhere else.
Any implementation that can't unwind from a cleanup form is almost
certainly broken, since it is very hard to be sure that code in the
cleanup forms isn't going to throw. For example, With-Open-File tries
to close the file if you unwind, and this operation could easily get
an error. The user could then throw out of the debugger, or a
condition handler might also throw.
Rob
∂28-Feb-87 2153 FAHLMAN@C.CS.CMU.EDU IF-BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 21:53:31 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 1 Mar 87 00:54:18-EST
Date: Sun, 1 Mar 1987 00:54 EST
Message-ID: <FAHLMAN.12282821608.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY
In-reply-to: Msg of 27 Feb 1987 18:41-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I oppose this proposal on aesthetic grounds, though I wouldn't fight too
hard against it if a majority of X3J13 felt otherwise. (I don't think
they will, however; we discussed this extended syntax during the
original language design and the extended form lost. Of course, we have
a different set of people involved now.) To me, the THEN and ELSE
clauses of an IF should be handled in a symmetrical manner, and I find
the extended form to be visually confusing. A PROGN wrapped around the
else forms makes the grouping obvious. (I might also observe that the
insertion of this PROGN can be fully automated.)
Whatever we decide about the merits of this proposal itself, I want to
VEHEMENTLY OBJECT to the rationale put forward in this proposal. I
think it is an extremely bad precedent to accept the argument that some
implementations have made a non-standard extension, their customers now
become upset when their code doesn't port to non-extended implementations,
Common Lisp has "egged them on" by allowing such extensions, and now we
have some sort of obligation (or at least a good reason) to accept the
extension into the official language unless it can be shown that this
would conflict with something else.
This same argument could be used to slip any number of unspeakable
horrors into the language. I'm sure that all of you can find some
extension used by your competitors and their customers that you
violently dislike. We can't allow this to become a principle of
language design. Each such case must be decided based on the aesthetic
judgement of the whole community (or their representatives), not by the
enthusiasms of one or two implementors.
We have said all along that non-standard extensions are OK, but that
only code written according to the manual can be expected to be
portable. If customers are having trouble, the right way to accommodate
them is to provide an optional compiler warning about non-standard
features such as this, and perhaps in this case a tool that will
automatically convert their code into legal Common Lisp.
-- Scott
∂28-Feb-87 2158 FAHLMAN@C.CS.CMU.EDU FORMAT-ATSIGN-COLON
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 21:58:01 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 1 Mar 87 00:58:48-EST
Date: Sun, 1 Mar 1987 00:58 EST
Message-ID: <FAHLMAN.12282822432.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: FORMAT-ATSIGN-COLON
In-reply-to: Msg of 27 Feb 1987 18:59-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support the proposal to explicitly state that either :@ or @: is
legal.
Spice currently seems to accept only :@, but a fix would not be
difficult (or if it is, that code is in even worse shape than I
thought).
∂28-Feb-87 2207 FAHLMAN@C.CS.CMU.EDU SHARPSIGN-BACKSLASH-BITS
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Feb 87 22:07:00 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 1 Mar 87 01:07:47-EST
Date: Sun, 1 Mar 1987 01:07 EST
Message-ID: <FAHLMAN.12282824063.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SHARPSIGN-BACKSLASH-BITS
In-reply-to: Msg of 27 Feb 1987 19:51-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support this proposal.
I think that we should seriously consider flushing both the bit and the
font attribute characters as part of the language spec. These would be
replaced by a character standard that would allow for both extended
character sets and for implementation-specific character attributes --
maybe fonts and bits, maybe something else, but unportable in any event.
Any such wholesale re-thinking of characters must be coordinated with
the Kanji standard from Japan, so it may not happen soon. KMP's
proposal is a useful patch in the meantime.
Spice Lisp currently accepts both short and long names, with the obvious
mapping, so we already comply with this proposal.
∂01-Mar-87 1649 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
Scott wonders why the types FUNCTION and LIST ought to be disjoint.
First, they are different things. We don't ask why NUMBER and LIST should
be disjoint - though one could argue that a unary representation of
numbers is good enough. There are a number of CL constructs intended to
build functions; CONS, LIST, and backquote are not among them. It seems
reasonable that exactly the range of those constructs in a given Lisp at a
given time should be precisely the things of type FUNCTION.
Second, there is a confusion between functions and expressions. An expression
is a piece of list structure (as represented in a running Lisp) that represents
a means of obtaining a value or values. EVAL accepts this representation and
produces that value or those values. An expression is not a function.
CONS, LIST, and backquote can build expressions, which can then be handed to
EVAL, whose purpose is to interpret expressions as programs.
Third, a programmer should expect that the Common Lisp types be well-defined
and well-founded. Confusing lists and functions does not serve that purpose.
Again, image the horror if LIST and NUMBER were not required to be disjoint and
that some lists were numbers.
Fourth, even if one requires that a function represented as a list whose
CAR hold some implementation-dependent unique object, a user can construct
such a list himself, which list is not a function. If FUNCTION and LIST are
disjoint, the user can be sure that the thing that FUNCTIONP says is a function
is the product of one of the CL constructs for producing functions, and if
applying the function results in an error, the bug is known to be in a place
where it is intended that functions are being produced and not in some
place where CONS, CAR, LIST, and backquote are operating on bad data.
Fifth, if you're interested in interpreter efficiency, you should advocate
some partial compilation technique rather than advocating eliminating
a structure reference (in place of a list structure reference).
Sixth, in balancing the scales between providing a meaningful function
type to the user and allowing implementors to use a cheap implementation
strategy, I think we are now in a position to regard as foolish the latter.
-rpg-
∂02-Mar-87 0718 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 07:18:33 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81610; Sun 1-Mar-87 17:36:48 EST
Date: Sun, 1 Mar 87 17:35 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870301173547.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
References: #+ (p358), #- (p359), *features* (p448)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 03/01/87
Problem Description:
No information is provided in the description of #+ and
#- (pp358-359) about what package the features are read on.
In some systems, the current package is used. Since there
is no wording to the contrary, it's reasonable to assume that
this would be done, but a consequence of this is that you
must be much more sensitive to the package you're in at any
given time when using #+ or #- even for system-provided
features. (This will be a big problem if we decide to require
that the LISP package can contain only the symbols in CLtL
because system-provided features will likely not have the
names of symbols on LISP and hence will require package
prefixes. Having a symbol named LISP:SYMBOLICS or LISP:LUCID
would not be possible, so something like #+Symbolics would
not be possible; you'd have to write #+SYSTEM:SYMBOLICS or
some such, which might get a read error in a non-Symbolics
implementation that didn't export SYMBOLICS from SYSTEM...)
In some systems, a canonical package (such as KEYWORD) is
used. This means that package prefixes are rarely necessary
in sharpsign conditionals for system-provided features
regardless of the current package or restrictions about what
may be in LISP. (For example, the KEYWORD package can have
any symbol so it's not a problem to push :SYMBOLICS or :LUCID
on *FEATURES*).
This has implications about what goes on the *FEATURES*
list (p448).
Voting Notes:
Choose only one of these proposals.
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):
Change the wording on pp358-359 so that it says that the
default package while reading feature specs is the keyword
package. Emphasize that other packages may be designated by
use of explicit package prefixes.
Add slightly redundant wording on page 448 to emphasize
that the symbols on *FEATURES* may be in any package but
that in practice they will mostly be on the keyword package
because that's the package #+/#- uses by default. If symbols
in a package other than keyword appear on *FEATURES*, they
will be seen by #+/#- only if marked by explicit package
prefixes in the written feature-spec.
Clarify that the package of the IEEE-FLOATING-POINT symbol
mentioned on p448 is KEYWORD.
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:CURRENT):
Change the wording on pp358-359 so that it says that the
current package is used to read feature specs.
Add redundant wording on page 448 to emphasize that the
symbols on *FEATURES* may be in more than one package and
that #+/#- will read symbols in the current package and
use EQL to search *FEATURES*.
Clarify that the package of the IEEE-FLOATING-POINT symbol
mentioned on p448 is LISP.
Rationale:
Since it's clear that Common Lisp is not going to handle all
of everyone's needs, one of the most important things we can
provide is a well-defined conditionalization system to allow
people to escape to native code where Common Lisp is deemed
inadequate.
Current Practice:
Some implementations bind *PACKAGE* while reading feature
specs and others do not.
Adoption Cost:
Changes to implementations to make them conform to either
of these should be fairly minor if not trivial.
Benefits:
#+/#- are not currently very portable. As such, there's
almost a bootstrapping problem where you need to #+/#-
conditionalize the setup of features since different systems
take them in different ways. Either of these changes would
make #+/#- work in a more portable way.
Conversion Cost:
Code which is implementation-conditionalized enough for this
to make a difference may require some changes. Even if those
changes turned out not to be completely trivial, my guess
from past experience in my own code is that maintainers of
such code would happily pay the cost of such changes in order
to have something which is more regular and predictably portable.
Aesthetics:
Most users would perceive this as a bug fix either to CLtL
or to certain implementations.
Discussion:
KMP thinks that nailing this down as soon as possible
is essential.
KMP's strong preference is for SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD.
Even if KEYWORD were chosen as the default package for
system-supplied symbols, it would be quite reasonable to
suggest that only vendors should add keyword symbols to
the *features* list, suggesting that users should add
features on their personal packages so that collisions due
to user applications were less likely. This idea might be
a subject of controversy though, so is definitely not part
of the proposal currently up for consideration.
∂02-Mar-87 0719 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-NUMBER
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 07:19:03 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81611; Sun 1-Mar-87 17:38:01 EST
Date: Sun, 1 Mar 87 17:37 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-NUMBER
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870301173706.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SHARPSIGN-PLUS-MINUS-NUMBER
References: #+ (p358), #- (p359), *features* (p448)
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 03/01/87
Problem Description:
Features which are not symbols are currently not allowed.
Unfortunately, machine names are desirable as features. Since
some machines are named only by a number (eg, 360, 3600, 8600,
8080, ...) there is no way to use these names as features.
Alternate, less mnemonic feature names, must be contrived.
Proposal (SHARPSIGN-PLUS-MINUS-NUMBER:OK)
Extend the definition of #+ and #- on pp358-359 to say that
integers are allowable as features. Define that the feature-spec
reader binds base to 10 so that people don't have to do #+7020 to
find the 3600 feature in base 8.
[We also need to nail down the rules for what package is used in
the feature-spec reader. I've put that in a separate proposal.]
Extend the definition of *features* on p448 to say that it is a
"list of symbols and/or numbers".
Rationale:
There is no deep-rooted reason why numbers shouldn't work.
The current restrictions are somewhat arbitrary. This would
allow arbitrary alphanumeric strings to be used as identifiers
in a well-defined way.
Current Practice:
Some implementations already allow this (though most probably
do not bind base to 10 -- I've seen some octal feature names).
Other implementations signal an error if they see what they
believe to be an invalid feature name (such as a number).
Adoption Cost:
Changes to implementations not already supporting this feature
would probably be very minor.
Benefits:
A restriction which seems arbitrary to some people would be removed.
Conversion Cost:
Some users would view this as an enhancement; others as a bug fix.
I don't think it would be seen in a negative light.
Aesthetics:
No issues not already addressed above.
Discussion:
KMP thinks that this would be a worthwhile extension.
∂02-Mar-87 0924 sandra%utah-orion@utah-cs.arpa Re: What does this bit of code do?
Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 09:24:23 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA28452; Mon, 2 Mar 87 10:26:17 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA19661; Mon, 2 Mar 87 10:26:10 MST
Date: Mon, 2 Mar 87 10:26:10 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8703021726.AA19661@utah-orion.ARPA>
Subject: Re: What does this bit of code do?
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>
Cc: gls@think.com, sandra%utah-orion@utah-cs.arpa,
common-lisp@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 27 Feb 87 13:14 EST
It occurs to me that one of the strangenesses of exiting from the cleanup
forms of an unwind-protect is that CLtL requires throw to find a matching
catch before proceeding to do anything, even though the throw might never
actually return control to that catch! Weird....
-Sandra
-------
∂02-Mar-87 0935 RAM@C.CS.CMU.EDU What does this bit of code do?
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Mar 87 09:35:21 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 2 Mar 87 12:36:02-EST
Date: Mon, 2 Mar 1987 12:35 EST
Message-ID: <RAM.12283211469.BABYL@>
From: Rob MacLachlan <RAM@λλ>
To: sandra%utah-orion@λutah-cs.arpa (Sandra J Loosemore)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: What does this bit of code do?
In-reply-to: Msg of 2 Mar 1987 12:26-EST from sandra%utah-orion at utah-cs.arpa (Sandra J Loosemore)
Date: Monday, 2 March 1987 12:26-EST
From: sandra%utah-orion at utah-cs.arpa (Sandra J Loosemore)
To: Kent M Pitman <KMP at scrc-stony-brook.arpa>
Re: What does this bit of code do?
It occurs to me that one of the strangenesses of exiting from the cleanup
forms of an unwind-protect is that CLtL requires throw to find a matching
catch before proceeding to do anything, even though the throw might never
actually return control to that catch! Weird....
Actually this is required anyway, since in the case where the catch
tag is not found, the error is required to be signalled without having
processed any unwind protect cleanups or done any unwinding. See the
Throw definition on page 142 in CLTL.
Rob
∂02-Mar-87 2127 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 21:27:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82808; Tue 3-Mar-87 00:28:02 EST
Date: Tue, 3 Mar 87 00:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 26 Feb 87 18:04 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>,
<870227115655.4.GLS@BOETHIUS.THINK.COM>,
<FAHLMAN.12282785586.BABYL@C.CS.CMU.EDU>,
The message of 28 Feb 87 22:10 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>,
<FAHLMAN.12282795558.BABYL@C.CS.CMU.EDU>,
The message of 1 Mar 87 19:49 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870303002615.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I am basically in favor of the proposal, with some minor amendments
noted below. I believe that the current definition of "function" in
Common Lisp was taken from pre-lexical-scoping Zetalisp and was not
properly reexamined when lexical scoping was thrown into the language,
and in addition got damaged by abstracting out some of the specific
behavior for functions that Zetalisp had.
Amendments:
How does the proposal affect page 47? I propose that it does not affect
it except for adding a note that the atomic type-specifier FUNCTION can
be used for discrimination, but the list type-specifier (FUNCTION ...)
cannot be. This is already true, but perhaps not clear.
As long as you are incompatibly changing the function FUNCTIONP,
eliminate it entirely. It doesn't do anything that TYPEP can't do.
I don't believe that APPLY and FUNCALL should say that their <function>
argument must be a function. In current Common Lisp these primitives
indirect through symbols; you imply in the examples that this feature
will be removed, but don't say so explicitly and don't mention it in the
adoption cost and conversion cost sections. I know that some people use
this programming style and I don't see any advantage to removing it.
Removing it would add incompatibility but wouldn't help clarify the
definition of "function". Just say that APPLY and FUNCALL accept either
a function or a symbol; given a symbol, they apply SYMBOL-FUNCTION to it
and try again.
By the way, it's important that using something other than a function or
a symbol as the <function> argument to APPLY or FUNCALL "is an error"
rather than "signals an error", because this leaves room for
implementation dependent extensions. For example, it allows Old Flavors
support; we need to be able to FUNCALL instances, but we surely don't
want to say that instances are functions.
I don't believe that the value returned by the FUNCTION special form
should be required to be a function. What does #'COND do? Currently
CLtL specifies that this returns "an object representing a special
form or macro". (That's reading pages 87 and 90; page 32 contradicts
this but I'm inclined to believe the specific function description
pages over the introductory pages.) What does
(macrolet ((foo (x) `(blatz ,x))) #'foo) do? CLtL doesn't say.
I don't care as much about this one, since I don't see how application
programs could be depending on it.
It might be wise to add LEXICAL-CLOSURE and INTERPRETED-FUNCTION data
types, to go along with the COMPILED-FUNCTION type that already exists.
These three would be disjoint subtypes of FUNCTION, but not necessarily
an exhaustive partition. There might be other ways to slice the space
of types, since it's not so clear what a function not inside a closure
is good for. Alternatively we could flush COMPILED-FUNCTION and say
that the subtypes of FUNCTION are all implementation-dependent. But I
think having COMPILED-FUNCTION without the others is weird.
With my suggested amendments, the only incompatible changes would be:
The FUNCTION type is now disjoint with CONS, SYMBOL, ARRAY,
NUMBER, and CHARACTER.
Compiled functions and closures must not be conses, symbols,
arrays, numbers, or characters.
The FUNCTIONP function is removed.
This seems like just as much of a burden for implementors, but much less
of a burden for application programmers since very few application
programs would be affected by these changes, especially if they are not
calling FUNCTIONP now because its definition is bankrupt.
∂02-Mar-87 2133 Moon@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 21:33:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82812; Tue 3-Mar-87 00:33:28 EST
Date: Tue, 3 Mar 87 00:31 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
In-Reply-To: <870301173547.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870303003144.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think I have voted on this about six times now over the years.
I continue to support SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD.
One note: It is important that #+foo:bar, when foo is not a recognized
package, not signal an error. Instead it should recognize that the
feature is not present. Without this robustness, it is difficult to
take advantage of the ability to use package prefixes with #+. Less
clear is the case where foo exists but does not export a symbol named
bar. I advocate signalling an error in this case, since it probably
indicates either a spelling error or a package-name conflict.
∂02-Mar-87 2143 Moon@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-BACKSLASH-BITS
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 21:43:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82824; Tue 3-Mar-87 00:44:23 EST
Date: Tue, 3 Mar 87 00:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-BACKSLASH-BITS
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12282824063.BABYL@C.CS.CMU.EDU>
Message-ID: <870303004240.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 1 Mar 1987 01:07 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I support this proposal.
So do I.
I think that we should seriously consider flushing both the bit and the
font attribute characters as part of the language spec.
Of course if we did that, the SHARPSIGN-BACKSLASH-BITS proposal would be
superseded, so you can't consistently support both. That's okay, nobody
is asking you to be consistent.
Removing bits and fonts wouldn't bother Symbolics. We don't use fonts,
and we wouldn't mind calling the bits feature part of our extensions to
Common Lisp rather than part of standard Common Lisp. However, it would
be a pity if all the people who have meta keys didn't get together and
agree on how they will be handled. I assume Common Lisp would not be
changed in a way that made it impossible to continue to support the bits
facility, for example, MAKE-CHAR would not be changed to add an optional
second argument that wasn't the bits.
Scott, perhaps you should write a formal cleanup proposal for this. Or
is not time yet.
These would be
replaced by a character standard that would allow for both extended
character sets and for implementation-specific character attributes --
maybe fonts and bits, maybe something else, but unportable in any event.
Any such wholesale re-thinking of characters must be coordinated with
the Kanji standard from Japan, so it may not happen soon. KMP's
proposal is a useful patch in the meantime.
I'm more concerned that adding a new thing (character sets) be done
thoughtfully than I am about removing an old thing (fonts).
∂02-Mar-87 2149 Moon@STONY-BROOK.SCRC.Symbolics.COM IF-BODY
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 21:49:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82825; Tue 3-Mar-87 00:49:36 EST
Date: Tue, 3 Mar 87 00:47 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12282821608.BABYL@C.CS.CMU.EDU>
Message-ID: <870303004754.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 1 Mar 1987 00:54 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Whatever we decide about the merits of this proposal itself, I want to
VEHEMENTLY OBJECT to the rationale put forward in this proposal. I
think it is an extremely bad precedent to accept the argument that some
implementations have made a non-standard extension, their customers now
become upset when their code doesn't port to non-extended implementations,
Common Lisp has "egged them on" by allowing such extensions, and now we
have some sort of obligation (or at least a good reason) to accept the
extension into the official language unless it can be shown that this
would conflict with something else.
This same argument could be used to slip any number of unspeakable
horrors into the language....
On the other hand, if a language standard doesn't evolve by observing
how people use it and what extensions they support, and then selecting
from that "gene pool" of extensions the ones that seem appropriate to
enshrine in a standard, then how does it evolve?
In other words, the mere fact that some people like this extension is
not sufficient reason to put it into the language, but it is certainly
sufficient reason to -discuss- putting it into the language.
∂02-Mar-87 2157 Moon@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 21:57:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82836; Tue 3-Mar-87 00:57:45 EST
Date: Tue, 3 Mar 87 00:56 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (revision 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870226224504.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870303005602.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support this with an amendment (already discussed with KMP).
The proposal as written implies that if an error occurs, NIL is the
only value returned. However, the pending error proposal states that
if an error occurs, two values are returned: the first is NIL and the
second is something else. I suggest amending the IGNORE-ERRORS proposal
to state that in the event of an error the first value returned is NIL
and unspecified additional values might be returned; this will avoid
the need to make an incompatible change later.
∂02-Mar-87 2302 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar 87 23:02:01 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82875; Tue 3-Mar-87 02:02:01 EST
Date: Tue, 3 Mar 87 02:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870303003144.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870303020058.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I agree with your premise that minimal error checking is warranted and
think that the extension of that the proper extension is (regrettably)
that improperly referencing a symbol as exported should not signal an
error. For example, our package SYSTEM is locked, so
#+SYSTEM:FOO
might signal an error on our system yet be important on someone else's.
This is rightly independent of the question of what package is the
default, though, so maybe yet another ballot item is in order.
∂03-Mar-87 0813 FAHLMAN@C.CS.CMU.EDU IF-BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 08:13:06 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Mar 87 11:13:50-EST
Date: Tue, 3 Mar 1987 11:13 EST
Message-ID: <FAHLMAN.12283458672.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY
In-reply-to: Msg of 3 Mar 1987 00:47-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
In other words, the mere fact that some people like this extension is
not sufficient reason to put it into the language, but it is certainly
sufficient reason to -discuss- putting it into the language.
Agreed. KMP's rationale seemed to go well beyond this position, implying
(it seemed to me) that if a small group had become "hooked" on an
extension, we should go not cause them any inconvenience by refusing to
add a harmless, if controversial, feature. Of course, that kind of
reasoning could be manipulated by any small group in order to get their
favorite crock into the language, as long as the change they wanted was
additive.
As I said before, I am only mildly opposed to this change on aesthetic
grounds and would go along with any strong community preference, as long
as we are not seen to be endorsing some position on additions like the
one presented above.
-- Scott
∂03-Mar-87 0848 gls@Think.COM SHARPSIGN-PLUS-MINUS-PACKAGE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Mar 87 08:47:50 PST
Received: from boethius by Think.COM via CHAOS; Tue, 3 Mar 87 11:46:46 EST
Date: Tue, 3 Mar 87 11:48 EST
From: Guy Steele <gls@Think.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870301173547.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870303114830.1.GLS@BOETHIUS.THINK.COM>
I support this change. --Guy
∂03-Mar-87 0917 gls@Think.COM SHARPSIGN-PLUS-MINUS-NUMBER
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Mar 87 09:17:32 PST
Received: from boethius by Think.COM via CHAOS; Tue, 3 Mar 87 12:16:25 EST
Date: Tue, 3 Mar 87 12:18 EST
From: Guy Steele <gls@Think.COM>
Subject: SHARPSIGN-PLUS-MINUS-NUMBER
To: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870301173706.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870303121816.2.GLS@BOETHIUS.THINK.COM>
I support this proposal. Question: what about potential numbers?
Should we require that a name such as 68020a be treated as a keyword
when reading for #+ or #- ?
--Guy
∂03-Mar-87 0957 gls@Think.COM FORMAT-ATSIGN-COLON
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Mar 87 09:57:20 PST
Received: from boethius by Think.COM via CHAOS; Tue, 3 Mar 87 12:56:42 EST
Date: Tue, 3 Mar 87 12:58 EST
From: Guy Steele <gls@Think.COM>
Subject: FORMAT-ATSIGN-COLON
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870227185938.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870303125841.5.GLS@BOETHIUS.THINK.COM>
I support this proposal. I regard failure to state that
the order of : and @ doe snot matter to be an lapse on my part;
I thought it was our intention that order not matter. Thanks
to KMP for catching this.
--Guy
∂03-Mar-87 1000 gls@Think.COM UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Mar 87 09:59:48 PST
Received: from boethius by Think.COM via CHAOS; Tue, 3 Mar 87 12:58:53 EST
Date: Tue, 3 Mar 87 13:00 EST
From: Guy Steele <gls@Think.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870227172152.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870303130052.7.GLS@BOETHIUS.THINK.COM>
I support choices 1C and 2C for this proposal.
This is one of those rare and happy cases where the
thing that is most general and powerful actually
happens to be the easiest to implement.
∂03-Mar-87 1002 gls@Think.COM SHARPSIGN-BACKSLASH-BITS
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Mar 87 10:02:33 PST
Received: from boethius by Think.COM via CHAOS; Tue, 3 Mar 87 12:56:59 EST
Date: Tue, 3 Mar 87 12:59 EST
From: Guy Steele <gls@Think.COM>
Subject: SHARPSIGN-BACKSLASH-BITS
To: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870227195124.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870303125900.6.GLS@BOETHIUS.THINK.COM>
I support this proposal.
∂03-Mar-87 1005 gls@Think.COM IF-BODY
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Mar 87 10:05:17 PST
Received: from boethius by Think.COM via CHAOS; Tue, 3 Mar 87 13:04:35 EST
Date: Tue, 3 Mar 87 13:06 EST
From: Guy Steele <gls@Think.COM>
Subject: IF-BODY
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <FAHLMAN.12282821608.BABYL@C.CS.CMU.EDU>
Message-Id: <870303130635.9.GLS@BOETHIUS.THINK.COM>
I agree with Scott's assessment of the IF-BODY proposal (though I think
the proposal was worth making). I would point out that one of the
reasons for including IF in the language is to have a simple primitive
that can easily be recognized, by people and by program-walkers alike,
as being the simplest conditional and not having implicit PROGNs as do
WHEN, UNLESS, and COND.
∂03-Mar-87 1106 KMP@STONY-BROOK.SCRC.Symbolics.COM potential numbers
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Mar 87 11:06:05 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83444; Tue 3-Mar-87 14:04:21 EST
Date: Tue, 3 Mar 87 14:04 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: potential numbers
To: gls@think.com
cc: kmp@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870303121816.2.GLS@BOETHIUS.THINK.COM>
Message-ID: <870303140437.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I personally think that it was a mistake for us to reserve such a
large syntactic space with no obvious purpose in mind, though I guess
a long tirade on the subject would be out of order here. Perhaps I'll
compose at least a detailed gripe if not a proposal for solution under
separate cover when I have more time.
[As an aside, it's curious to notice that in some implementations
(PUSH ':68020a *FEATURES*)
or more conservatively syntaxwise:
(PUSH (LET ((*PACKAGE* (FIND-PACKAGE "KEYWORD")))
(READ-FROM-STRING "68020a")) *FEATURES*)
and later using #+68020a might `work' even without the writer
having to know whether that token resolved as a number or a symbol.
Of course, some implementations might reasonably signal an error
when they saw it, which makes it ultimately non-portable and only
topic for an offbeat aside such as this.]
I do think that as with non-existent and non-exported symbols,
tolerant reading should again be in order. Remember
that the purpose of #+/#- is to bridge the gap to
implementation-specific extensions, and that while reading the name
of the extension, we're in a fuzzy gray area where we do well to
walk as lightly as possible. If people are amenable, I'll add this
to the proposal I'm accumulating for cautious package reading in
the feature-spec context.
∂03-Mar-87 1151 gls@Think.COM SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Mar 87 11:51:43 PST
Received: from boethius by Think.COM via CHAOS; Tue, 3 Mar 87 14:50:58 EST
Date: Tue, 3 Mar 87 14:52 EST
From: Guy Steele <gls@Think.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870303125939.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870303145255.4.GLS@BOETHIUS.THINK.COM>
KMP has pointed out that I was not clear which of
two proposals I supported. I prefer that symbols
following #+/#- be in th ekeyword package by default.
--Guy
∂03-Mar-87 1209 KMP@STONY-BROOK.SCRC.Symbolics.COM IF-BODY
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Mar 87 12:09:08 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83490; Tue 3-Mar-87 14:46:30 EST
Date: Tue, 3 Mar 87 14:46 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY
To: gls@Think.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870303130635.9.GLS@BOETHIUS.THINK.COM>
Message-ID: <870303144644.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
While I would certainly agree that your opinions should be included in
a ballot item, I think it's important that this committee not make a
policy of keeping any serious proposal from a full vote. While none of
us on this committee is likely to accuse another of trying to use
underhanded tactics to keep a topic from reaching the agenda, proposals
that were received from the outside should not be subject to veto within
this committee. Our charter should be only to frame the question clearly
and provide any appropriate advice that we can. Ultimately, to insure
the X3J13 fairness doctrine, I think we must allow for a full review.
Having said this, I think that if outsiders should be entitled to not
have serious proposals stifled in this committee, then it's only reasonable
that insiders should enjoy the same courtesy. As such, why don't you
or Scott work out an alternate voting position and rationale and add it
into my original proposal. My feeling is that you should be allowed to
say whatever you like about the issue, but should not modify my proposal
or rationale. The introduction of alternatives should be primarily
additive in nature -- analagous to a debate.
I think this is a good example of exactly the process we should
be trying to encourage. I think a pocket veto is outside of our authority
because it does no afford due process. If the group voted to allow such
a veto power, it would be ok, but I would not encourage them to do so
and I doubt that they would.
Also, a pocket veto does not afford a proper historical record.
∂03-Mar-87 1228 FAHLMAN@C.CS.CMU.EDU IF-BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 12:28:01 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Mar 87 15:28:47-EST
Date: Tue, 3 Mar 1987 15:28 EST
Message-ID: <FAHLMAN.12283505086.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY
In-reply-to: Msg of 3 Mar 1987 14:46-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I don't think any of us intended to interfere with your right to
bring this issue before X3J13 if you want to. I don't like this
proposal, but I will defend to the death (well...until it hurts, anyway)
your right to present the proposal. I do think it is perfectly
within our charter to try to debug proposals and rationales, as well as
to propose alternatives. If the person making the proposal insists upon
going forward with the original formulation, fine; the issue should go
to X3J13 along with the arguments we have gathered pro and con.
For people's convenience, I'd like to see us produce two packages of
proposals: proposals upon which we have reached a consensus and which
the cleanup committee as a whole endorses, and proposals favored by
certain individuals, about which there is some significant disagreement.
-- Scott
∂03-Mar-87 1234 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Mar 87 12:34:05 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83555; Tue 3-Mar-87 15:33:07 EST
Date: Tue, 3 Mar 87 15:33 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE
To: edsel!bhopal!jonl@navajo.stanford.edu
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8703031639.AA00314@bhopal.edsel.com>
Message-ID: <870303153323.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
The whole point to all this is that a feature is a packaged symbol.
#+ and #- use *FEATURES* but other things may as well. Since string
comparison is not used, it's important that the package be specified
or the symbol may not be found by all programs.
There are four possible cases:
* #+/#- read forms with default current package. IEEE-... on LISP package.
This means you write #+IEEE-... or (MEMBER 'IEEE-... *FEATURES*).
* #+/#- read forms with default current package. IEEE-... on KEYWORD package.
This means you write #+:IEEE-... or (MEMBER ':IEEE-... *FEATURES*).
* #+/#- read forms with default KEYWORD package. IEEE-... on LISP package.
This means you write #+LISP:IEEE-... or (MEMBER 'IEEE-... *FEATURES*).
* #+/#- read forms with default KEYWORD package. IEEE-... on KEYWORD package.
This means you write #+IEEE-... or (MEMBER ':IEEE-... *FEATURES*).
I believe that items 1 and 4 above are most internally consistent.
Since people are leaning toward default keyword package, This selects
item 4 as the obvious intended behavior. The clarification is intended
to preclude an interpretation such as item 3, which is technically
consistent with the current wording even after the proposed change
unless the package clarification is included.
∂03-Mar-87 1250 KMP@STONY-BROOK.SCRC.Symbolics.COM (treatment of) IF-BODY
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Mar 87 12:50:02 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83576; Tue 3-Mar-87 15:47:29 EST
Date: Tue, 3 Mar 87 15:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: (treatment of) IF-BODY
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12283505086.BABYL@C.CS.CMU.EDU>
Message-ID: <870303154743.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Separating controversial from uncontroversial ones sounds fine.
I think it's worth a disclaimer on the uncontroversial ones that says that
just because we support them doesn't mean people shouldn't read them before
voting. Then no one can accuse us of trying to sneak anything by.
The ball is in your court, then, for creating an alternate proposal to sit
with this in the packet of muddy issues to get full review.
∂03-Mar-87 1710 Moon@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Mar 87 17:10:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83923; Tue 3-Mar-87 20:10:03 EST
Date: Tue, 3 Mar 87 20:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870303020058.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870303200935.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 3 Mar 87 02:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I agree with your premise that minimal error checking is warranted and
think that the extension of that the proper extension is (regrettably)
that improperly referencing a symbol as exported should not signal an
error. For example, our package SYSTEM is locked, so
#+SYSTEM:FOO
might signal an error on our system yet be important on someone else's.
I'm forced to conclude that you're right. So any time the symbol following
#+ (or #-) cannot be interned, for whatever reason, the feature is deemed
to be not present and no error is signalled.
This is rightly independent of the question of what package is the
default, though, so maybe yet another ballot item is in order.
I have no opinion about whether it is better to bundle together closely
related issues or to keep them separate. One way keeps us more consistent,
the other way makes it look like we're accomplishing more (and we really
do accomplish more if one issue is controversial and the other isn't).
∂03-Mar-87 1843 FAHLMAN@C.CS.CMU.EDU (treatment of) IF-BODY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 18:43:17 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 3 Mar 87 21:43:59-EST
Date: Tue, 3 Mar 1987 21:43 EST
Message-ID: <FAHLMAN.12283573387.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: (treatment of) IF-BODY
In-reply-to: Msg of 3 Mar 1987 15:47-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
OK, I take it that we have not persuaded you to alter either your
proposal or the rationale you present for it. In that case, I'll write
up an opposing view.
I'm not sure if an aternate proposal is the right mechanism here, since
the aternative is not to do anythign about this, but I'll put it into
that form for now.
-- Scott
∂03-Mar-87 2118 FAHLMAN@C.CS.CMU.EDU IF-BODY:NO
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Mar 87 21:18:11 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Mar 87 00:18:56-EST
Date: Wed, 4 Mar 1987 00:18 EST
Message-ID: <FAHLMAN.12283601602.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: IF-BODY:NO
Issue: IF-BODY
References: IF (p115)
Category: ENHANCEMENT
Edit history: Response by SEF 3/3/87
to Revision 1 by KMP 02/27/87
Problem Description:
From KMP's IF-BODY:YES proposal:
IF only allows 2 or 3 arguments.
Because CLtL specifies that upward compatible extensions are permissible
when they don't interfere with the language semantics, many implementations
have provided an extended syntax for IF that looks like:
(IF test then {else}*)
The problem is that systems providing this extension do not provide
error checks that tell developers of code that will be ported when they're
likely to lose.
As such, this is a source of frustration for users, only a small fraction of
which care about arguing about whether more than three arguments is aesthetic.
They just want their programs to port without hassle. CLtL has egged on the
problem by explicitly suggesting that such extensions were permissible.
Proposal (IF-BODY:NO):
Leave IF as it is currently specified in CLtL.
Rationale:
The proposed change would destroy the symmetry of the THEN and ELSE
clauses in an IF expression, and would lead to a format that in the
opinion of many is visually confusing. IF is supposed to be the
simplest conditional form, from which all the others are built.
Current Practice:
Some implementations already provide extended-format IF as a
non-standard extension. They could continue to do so.
Adoption Cost:
Zero if we don't change IF; a small effort for implementors if we do
make the change.
Benefits:
Zero if we don't change IF. In my view, the benefits of adopting the
change are slightly negative; KMP and others feel it is slightly positive.
Conversion Cost:
Zero if we don't change IF. Since the proposed extension is an
upward-compatible extension most user code would not have to be
altered if the change is adopted, except in implementations extend IF
in some different way, incompatible with this one.
Since IF is defined as a special form, code walkers and other
code-understanding tools would have to be altered to accommodate the
extended format.
If we don't change, users who wish to eliminate extended-form IF's
from their code can do this easily by adding an explicit PROGN around
the ELSE forms. This can be done automatically by any code-walker.
Aesthetics:
There is disagreement on the aesthetics of the proposed change. KMP
argues that nobody is forced to write code using the extension.
However, my principal objection to this change is that it makes code
harder for humans to read, and if the change is adopted we will all be
required to read a lot of code that uses the extended-form IF.
Discussion:
I am only mildly opposed to this change on aesthetic grounds. I would
yield on this if a clear majority of Common Lisp users felt that the
change was beneficial. However, I don't think that such a majority
exists, and I adhere to the view that purely aesthetic changes should
only be made if there is a very clear consensus that the improvement is
worth the cost. In this case we can't even agree that the change would
be an improvement.
I would like to go on record as objecting in principle to KMP's other
argument for this change: that some manufacturers have provided the
extension, that their users are subject to some inconveninece when
moving to standard Common Lisp systems, and that we should alter Common
Lisp in a way that is controversial just to accommodate these users. I
feel that this argment, if accepted, would set a terrible precedent: any
small faction that wants to force some upward-compatible change into the
language would just have to implement the change as an extension and
then claim inconvenience to their users if it is not adopted as part of
the standard.
If an extension becomes genuinely popular, we should
consider adopting it; I am only objecting to the idea that we have some
obligation to adopt marginal extensions rather than inconvenience the
people who are using them.
Incompatible extensions should be clearly documented as such, and users
should stick to the base language in code that is meant to be portable.
A manufacturer can aid these users by providing an optional compiler
mode that warns about the use of non-portable extensions and/or by
providing automatic tools for turning extended code into standard code.
∂04-Mar-87 0654 gls@Think.COM IF-BODY
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 4 Mar 87 06:53:55 PST
Received: from boethius by Think.COM via CHAOS; Wed, 4 Mar 87 09:52:41 EST
Date: Wed, 4 Mar 87 09:54 EST
From: Guy Steele <gls@Think.COM>
Subject: IF-BODY
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, gls@think.com
In-Reply-To: <870303144644.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870304095439.1.GLS@BOETHIUS.THINK.COM>
I certainly did not mean to imply that this proposal, or any proposal,
should be killed in committee, or that any part of the proposal should
be deleted. However, I think that Scott's remarks concerning the nature
of the rationale are well taken, and should also be included as
commentary on the proposal. Individuals preparing proposals may choose
to take his arguments into account when determining what else to propose
and what justifications to give. You have framed a question clearly; he
has provided advice that I consider appropriate.
∂04-Mar-87 0934 edsel!bhopal!jonl@navajo.stanford.edu IMPORTations into keyword package
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87 09:34:27 PST
Received: by navajo.stanford.edu; Wed, 4 Mar 87 08:44:54 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA04128; Wed, 4 Mar 87 08:02:11 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA01992; Wed, 4 Mar 87 07:59:14 PST
Date: Wed, 4 Mar 87 07:59:14 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8703041559.AA01992@bhopal.edsel.com>
To: navajo!Common-Lisp%sail@navajo.stanford.edu
Subject: IMPORTations into keyword package
Does anyone have a need/opinion about the meaning of importing an
"interned"symbol into the keyword package? ("interned" means already
"homed" in some package, such as Lisp or User). CLtL, page 175 strongly
suggests that "keywords" ought not to be imported into other packages
("keywords" means "present and owned by the keyword package"); but there
is no suggestion about the other direction.
Consider, for example doing (import 't (find-package "KEYWORD")). After
this step, you would have (eq t :t), which might seem desirable; but you
wouldn't have (keywordp :t) because t is still owned by the Lisp package.
-- JonL --
∂04-Mar-87 1601 RPG FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
Moon makes some good points.
Moon writes:
``How does the proposal affect page 47? I propose that it does not affect
it....''
Agreed.
Moon writes:
``As long as you are incompatibly changing the function FUNCTIONP,
eliminate it entirely. It doesn't do anything that TYPEP can't do.''
Agreed.
Moon writes:
``I don't believe that the value returned by the FUNCTION special form
should be required to be a function. What does #'COND do? Currently
CLtL specifies that this returns "an object representing a special
form or macro". (That's reading pages 87 and 90; page 32 contradicts
this but I'm inclined to believe the specific function description
pages over the introductory pages.)''
This is an interesting point. To summarize the pages to which Moon refers,
page 32 states that FUNCTION produces a function, page 87 states that
(FUNCTION <symbol>) returns the functional definition associated with
<symbol> (see SYMBOL-FUNCTION), and page 90 states that SYMBOL-FUNCTION
returns the function definition associated with the symbol given to it
as an argument, but that if the symbol represents a special form (like COND)
SYMBOL-FUNCTION might return some other object. It is an error to attempt
to invoke that other object.
I propose that we clarify this contradictory set of statements by changing
page 32 as I proposed and leaving page 87 alone; page 90 would be amended
to state that SYMBOL-FUNCTION always returns a function if the symbol is
FBOUNDP, but that it is an error to invoke that function if the symbol
represents a special form. That is, even if the symbol represents a
special form, it has a function in its function cell, but invoking that
function is an error. Some implementations might signal that error.
Anyone with an implementation in which this makes a difference should
speak up.
I think that FUNCALL and APPLY really ought to be legal only on functions
and that the programmer should program his intentions.
Moon writes:
``For example, it allows Old Flavors support; we need to be able to
FUNCALL instances, but we surely don't want to say that instances are
functions.''
Although I have little sympathy for Old Flavors, I would suggest that in
their implementation instances be made a subtype of FUNCTION.
-rpg-
∂04-Mar-87 1924 MASINTER.PA@Xerox.COM meeting
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Mar 87 19:23:54 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 04 MAR 87 19:23:38 PST
From: MASINTER.PA@Xerox.COM
Date: 4 Mar 87 19:23:15 PST
Subject: meeting
To: cl-cleanup@sail.stanford.edu
Message-ID: <870304-192338-2282@Xerox>
There is an object-system meeting on Monday, which might interfere with
some of the folks.
I'd prefer to meet on Sunday, 2-4, at Xerox. If we can agree on some
items to distribute to X3J13, that will give enough time to make copies
for distribution on Monday afternoon.
∂04-Mar-87 2050 FAHLMAN@C.CS.CMU.EDU meeting
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Mar 87 20:50:12 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 4 Mar 87 23:50:54-EST
Date: Wed, 4 Mar 1987 23:50 EST
Message-ID: <FAHLMAN.12283858645.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: meeting
In-reply-to: Msg of 4 Mar 1987 22:23-EST from MASINTER.PA at Xerox.COM
If the meeting is Sunday 2-4, I'll be there.
∂05-Mar-87 0657 gls@Think.COM FUNCTION-TYPE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Mar 87 06:56:09 PST
Received: from boethius by Think.COM via CHAOS; Thu, 5 Mar 87 09:46:56 EST
Date: Thu, 5 Mar 87 09:48 EST
From: Guy Steele <gls@Think.COM>
Subject: FUNCTION-TYPE
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <8703050002.AA06014@Think.COM>
Message-Id: <870305094854.1.GLS@BOETHIUS.THINK.COM>
Date: 04 Mar 87 1601 PST
From: Dick Gabriel <RPG@sail.stanford.edu>
Moon makes some good points.
...
Moon writes:
``I don't believe that the value returned by the FUNCTION special form
should be required to be a function. What does #'COND do? Currently
CLtL specifies that this returns "an object representing a special
form or macro". (That's reading pages 87 and 90; page 32 contradicts
this but I'm inclined to believe the specific function description
pages over the introductory pages.)''
This is an interesting point. To summarize the pages to which Moon refers,
page 32 states that FUNCTION produces a function, page 87 states that
(FUNCTION <symbol>) returns the functional definition associated with
<symbol> (see SYMBOL-FUNCTION)...
One question is: can COND, which is not a function, be said to
have a functional definition? Also, page 87 states "fn is interpreted
as if it had appeared in the functional position of a function
invocation." Because (COND ...) is not a function invocation,
one could claim that #'COND cannot be understood in this way to
be meaningful. I have been trying to remember what I meant when
that text was written, but I can't.
[It feels really weird to be constantly examining hermeneutically
text that I wrote myself.]
--Guy
∂05-Mar-87 1033 johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK evalhook, eval-when
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 5 Mar 87 10:33:18 PST
Received: from ucl-cs-vax1 by mv1.Cs.Ucl.AC.UK via Ethernet with SMTP
id af10318; 5 Mar 87 18:03 WET
Received: from 44d.cs.ucl.ac.uk by vax1.Cs.Ucl.AC.UK with SMTP id aa02689;
5 Mar 87 17:17 GMT
Received: from cs.ucl.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP
id a000487; 5 Mar 87 17:12 GMT
From: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
Date: Wed, 4 Mar 87 20:57:09 gmt
Message-Id: <14401.8703042057@cvaxa.sussex.ac.uk>
To: common-lisp@sail.stanford.edu
Subject: evalhook, eval-when
Can anyone help me with how *EVALHOOK* and EVAL-WHEN should operate in
an incrementally compiled Common Lisp ?
ClTl, p321
"The evaluator is typically implemented as an interpreter that
traverses the given form recursively; performing each step of the
computation as it goes. An interpretive implementation is not
required, however. A permissible alternative approach is for the
evaluator first to completely compile the form into machine-
executable code and then invoke the resulting code. This technique
virtually eliminates incomptibilities between interpreted and
compiled code, but also renders the `evalhook' mechanism relatively
useless."
It would be ludicrous to compile a run-time check on the value of
*EVALHOOK* along with every form processed by the compiler. Perhaps one
could have a new declaration, COMPILE-HOOKS, to force this. I'm tempted
to leave *EVALHOOK* and friends out of my Lisp (POPLOG Common Lisp)
entirely, seeing as they are so obviously interpreter-oriented, but then
people use them in software that's supposed to be portable, eg Portable
Common Loops.
Now for EVAL-WHEN. The problem here is that the concepts of COMPILE,
LOAD, and EVAL phases don't apply in an incrementally compiled Lisp -
POPLOG operates a READ-COMPILE-EXECUTE-PRINT loop, not a READ-EVAL-PRINT
loop. The only distinction that can be sensibly made is between having a
form evaluated 'now' (ie at the time the EVAL-WHEN form is processed) or
'in due course' (ie when it would have been executed in the normal
course of events). So POPLOG makes
(let ((x 1) (y 2))
(compiler-let ((x 100) (y 200))
(* (eval-when (compile) (+ x y)) 2)))
produce 600, and
(let ((x 1) (y 2))
(compiler-let ((x 100) (y 200))
(* (eval-when (eval) (+ x y)) 2)))
produce 6.
However, while this interpretation of EVAL-HOOK seems sensible to me, it
may not be what someone who had written the above code would have
expected. Again, PCL gives me grief in this respect - the way it uses
EVAL-WHEN doesn't seem to fit this interpretation.
John Williams,
University of Sussex, Cognitive Sciences, Brighton, BN1 9QN, England
Tel - (0273) 606755
UUCP: ...mcvax!ukc!cvaxa!johnw
ARPANET : johnw%uk.ac.sussex.cvaxa@cs.ucl.ac.uk
JANET johnw@cvaxa.sussex.ac.uk
∂05-Mar-87 1037 RPG FUNCTION-TYPE & Hermeneutics
To: cl-cleanup@SAIL.STANFORD.EDU
Now you're talking, Quux! Actually, if you had been involved with
CLOS, you would have been quite used to reading text that way.
However, to be serious (sic), the key to understanding the linkage
between pages 87 and 90 is the phrasing:
``In particular, if FN is a symbol, the functional definition associated
with that symbol is returned; see SYMBOL-FUNCTION [which is page 90].''
Then on page 90 the relevant text starts out,
``SYMBOL-FUNCTION returns the current global function definition
named by SYMBOL....''
The question is whether the semi-colon followed by ``see SYMBOL-FUNCTION''
means that SYMBOL-FUNCTION is what FUNCTION is equivalent to or that
the definition of SYMBOL-FUNCTION is enlightening in terms of understanding
what FUNCTION does when the SYMBOL represents a function and not a special
form.
Similarity of phrasing, collocation, and the linkage of ``see..''
implies, to me, that (FUNCTION <symbol>) and (SYMBOL-FUNCTION <symbol>)
are intended to be synonymous. I suggest we clarify this as I proposed
earlier.
-rpg-
∂05-Mar-87 1424 Moon@STONY-BROOK.SCRC.Symbolics.COM evalhook, eval-when
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Mar 87 14:24:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 86002; Thu 5-Mar-87 16:55:42 EST
Date: Thu, 5 Mar 87 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: evalhook, eval-when
To: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <14401.8703042057@cvaxa.sussex.ac.uk>
Message-ID: <870305165452.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
When EVAL-WHEN refers to "compile", it means the translation of a source
file into a binary file, rather than the conversion of list structures
into machine language instructions. EVAL-WHEN has to do with the
distinction between doing things in a file, which will later be loaded
into some other Lisp world, and doing things in the current Lisp world.
So I don't think your incrementally compilation technique affects
EVAL-WHEN at all.
I have no opinion on the *EVALHOOK* issue.
∂05-Mar-87 1513 Moon@STONY-BROOK.SCRC.Symbolics.COM evalhook, eval-when
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Mar 87 14:24:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 86002; Thu 5-Mar-87 16:55:42 EST
Date: Thu, 5 Mar 87 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: evalhook, eval-when
To: John Williams <johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <14401.8703042057@cvaxa.sussex.ac.uk>
Message-ID: <870305165452.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
When EVAL-WHEN refers to "compile", it means the translation of a source
file into a binary file, rather than the conversion of list structures
into machine language instructions. EVAL-WHEN has to do with the
distinction between doing things in a file, which will later be loaded
into some other Lisp world, and doing things in the current Lisp world.
So I don't think your incrementally compilation technique affects
EVAL-WHEN at all.
I have no opinion on the *EVALHOOK* issue.
∂05-Mar-87 2057 gls@Think.COM FUNCTION-TYPE & Hermeneutics
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Mar 87 20:57:35 PST
Received: from boethius by Think.COM via CHAOS; Thu, 5 Mar 87 17:42:50 EST
Date: Thu, 5 Mar 87 17:44 EST
From: Guy Steele <gls@Think.COM>
Subject: FUNCTION-TYPE & Hermeneutics
To: RPG@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <8703051937.AA14825@Think.COM>
Message-Id: <870305174444.5.GLS@BOETHIUS.THINK.COM>
Date: 05 Mar 87 1037 PST
From: Dick Gabriel <RPG@sail.stanford.edu>
However, to be serious (sic)...
Similarity of phrasing, collocation, and the linkage of ``see..''
implies, to me, that (FUNCTION <symbol>) and (SYMBOL-FUNCTION <symbol>)
are intended to be synonymous. I suggest we clarify this as I proposed
earlier.
-rpg-
I agree with you. However, to be non-serious:
[p. 87]
``In particular, if FN is a symbol, the functional definition associated
with that symbol is returned; see SYMBOL-FUNCTION [which is page 90].''
...
The question is whether the semi-colon followed by ``see SYMBOL-FUNCTION''
means that SYMBOL-FUNCTION is what FUNCTION is equivalent to or that
the definition of SYMBOL-FUNCTION is enlightening in terms of understanding
what FUNCTION does when the SYMBOL represents a function and not a special
form.
The question is really whether the semicolon means the rest of the line is
to be ignored. After the semicolon, the next word should be "sure".
--Q
∂06-Mar-87 1026 RAM@C.CS.CMU.EDU evalhook, eval-when
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Mar 87 10:24:44 PST
Received: ID <RAM@C.CS.CMU.EDU>; Fri 6 Mar 87 13:24:19-EST
Date: Fri, 6 Mar 1987 13:24 EST
Message-ID: <RAM.12284268851.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: John Williams <johnw%cvaxa.sussex.ac.uk@CS.UCL.AC.UK>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: evalhook, eval-when
In-reply-to: Msg of 4 Mar 1987 15:57-EST from John Williams <johnw%cvaxa.sussex.ac.uk at Cs.Ucl.AC.UK>
Date: Wednesday, 4 March 1987 15:57-EST
From: John Williams <johnw%cvaxa.sussex.ac.uk at Cs.Ucl.AC.UK>
To: common-lisp at sail.stanford.edu
Re: evalhook, eval-when
[...] I'm tempted to leave *EVALHOOK* and friends out of my Lisp
(POPLOG Common Lisp) entirely, seeing as they are so obviously
interpreter-oriented, but then people use them in software that's
supposed to be portable, eg Portable Common Loops.
Since Common Lisp definitely allows compile-only implementations, it
is entirely within your rights to fail to support evalhook. A strict
interpretation might require the variables and functions to be
defined, but they wouldn't have to do anything. For this reason, I
think evalhook should be flushed from the language. Programs that
require EVALHOOK are broken.
Now for EVAL-WHEN. The problem here is that the concepts of COMPILE,
LOAD, and EVAL phases don't apply in an incrementally compiled Lisp -
POPLOG operates a READ-COMPILE-EXECUTE-PRINT loop, not a READ-EVAL-PRINT
loop. The only distinction that can be sensibly made is between having a
form evaluated 'now' (ie at the time the EVAL-WHEN form is processed) or
'in due course' (ie when it would have been executed in the normal
course of events).
Yes, there are major problems with the specification of EVAL-WHEN.
The compiler cleanup committee is currently working on this, but we
probably can't offer a great deal of help since the only proposal that
deals with these problems advocates flushing EVAL-WHEN and replacing
it with new special forms.
Although Moon presumably knows the ancestral meaning of EVAL-WHEN, I
don't agree with his interpretation of it on the basis of dumping to
files. The rules for evaluation should exist independently of any
semantics of COMPILE-FILE.
My current opinion that there are only three EVAL-WHEN situation
lists that can be used in portable code:
(compile load eval)
(load eval)
(compile eval)
The reason for this restriction is that other situation lists allow
programs to "tell the difference" between a compiled and an interpreted
implementation.
Given that only these situation lists are used, a compile-only system
can entirely ignore the EVAL situation, and interpret COMPILE as "do
it now" and LOAD as "do it eventually." In any situation where the
EVAL-WHEN body is not evaluated, the result of the EVAL-WHEN is NIL.
If you believe my EVAL-WHEN rules, then both of your examples are
incorrect, since the "eventual evaluation" of both EVAL-WHEN forms
will be NIL, not a number.
Rob
∂06-Mar-87 1350 KMP@STONY-BROOK.SCRC.Symbolics.COM PEEK-CHAR-READ-CHAR-ECHO
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Mar 87 13:50:25 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 86940; Fri 6-Mar-87 16:49:50 EST
Date: Fri, 6 Mar 87 16:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PEEK-CHAR-READ-CHAR-ECHO
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870306164908.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: PEEK-CHAR-READ-CHAR-ECHO
References: READ-CHAR (p379), UNREAD-CHAR (p379), PEEK-CHAR (p379),
MAKE-ECHO-STREAM (p330), Streams (p327-328),
READ-PRESERVING-WHITESPACE (p376),
READ-DELIMITED-LIST (p377)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 03/06/87
Problem Description:
The interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM is not made adequately clear about how many times
a particular character may be echoed and at what time such echo
is permissible.
For example, if *STANDARD-INPUT* is a non-interactive stream with
echo to the terminal, and the following code is executed:
(PROGN (PEEK-CHAR) (PRIN1 'XXX)
(PEEK-CHAR) (PRIN1 'XXX)
(READ-CHAR) (PRIN1 'XXX)
(UNREAD-CHAR) (READ-CHAR))
what is seen on the terminal? There are at least four possibilities:
[1] Characters are echoed when first seen:
AXXXXXXXXX
[2] Characters are echoed whenever seen by PEEK-CHAR or READ-CHAR.
Characters are not unechoed by UNREAD-CHAR.
AXXXAXXXAXXXA
[3] Characters are not echoed by PEEK-CHAR but are echoed by READ-CHAR.
No `unecho' action is done by UNREAD-CHAR.
XXXXXXAXXXA
[4] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR does not `unecho'. Operationally equivalent to [2]:
AXXXAXXXAXXXA
[5] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR unechos (a magic Erase character must be
presupposed for display terminals, a file stream that can randomly
access during output and/or back up must be presupposed for files,
paper terminals just lose):
A<Erase>XXXA<Erase>XXXA<Erase>XXXA
[6] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. The first time
a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not echo,
re-fetching the char by READ-CHAR doesn't echo. Operationally
equivalent to [1]:
AXXXXXXXXX
[7] PEEK-CHAR is implemented by peeking and does not echo. The first
time a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not
echo, re-fetching the char by READ-CHAR doesn't echo:
XXXXXXAXXX
This list is not believed to be exhaustive. It is only to illustrate
of the variety of possible ways in which the current specification can
be implemented without technically being in conflict with the written
word of CLtL. Obviously not all of these interpretations are considered
useful by all people, but usefulness has not been determined to be
criterial in satisfying the specification.
The description of streams (p327-328) is also [probably deliberately]
fuzzy on this issue as it relates to operating systems on which echoing
is done by the operating system. That is, some systems are line-at-a-time
and all READ-CHAR and PEEK-CHAR operations happen after issues of echo
have long since been resolved by a system call that reads and echos input
a line at a time. Other systems are character-at-a-time and these issues
hit home in a different way. It will probably be necessary to continue
leaving things slightly unspecified in order to accomodate the native
style of the variety of operating systems now trying to support Common
Lisp, but we should be more up front about the game we are playing. (For
example, code which must port between character-at-a-time and
line-at-a-time systems must be more careful about whether it does
newline-preceded or newline-terminated output than many CL programmers
might realize given the current wording.) Additionally, though, we should
be on the lookout for less ambitious goals involving only partial
compatibility to improve the situation wherever we can find a way to.
Abstract functions READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST
are implicitly affected by any decisions made on this issue since their
descriptions involve the use of UNREAD-CHAR and PEEK-CHAR, respectively.
Proposal (PEEK-CHAR-READ-CHAR-ECHO:READ-CHAR):
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (such as an interactive stream to the terminal or a
stream created by MAKE-ECHO-STREAM), the character will be echoed on
the stream at the time this operation is performed.
Ammend the description of UNREAD-CHAR to say that when the stream
is an echo stream (such as an interactive stream to the terminal or a
stream created by MAKE-ECHO-STREAM), no attempt will be made to undo
any echoing of the character which might already have been done on
the stream.
Ammend the description of PEEK-CHAR to say that when the stream is
an echo stream (such as an interactive stream to the terminal or a
stream created by MAKE-ECHO-STREAM), characters which are only peeked
at are not echoed. Note however that in the case that the PEEK-TYPE
argument is not NIL, the characters which are passed by PEEK-CHAR
are treated as if by READ-CHAR, and so are echoed.
Ammend the description of streams to mention that interactive streams
to the terminal, such as the one held by *TERMINAL-IO*, have the same
rules for the time at which echoing must occur as do streams created
by READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Ammend the description of abstract input functions
READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
that they are implicitly affected by these new echoing rules of
READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Note: This is consistent with behavior [3] in the problem description.
Proposal (PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR):
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (such as an interactive stream to the terminal or a
stream created by MAKE-ECHO-STREAM), the character will be echoed on
the stream the first time those characters are seen. (Characters
which are not echoed by READ-CHAR are those which were put there by
UNREAD-CHAR and hence are assumed to have been echoed already by a
previous call to READ-CHAR.)
Ammend the description of UNREAD-CHAR to say that when the stream
is an echo stream (such as an interactive stream to the terminal or a
stream created by MAKE-ECHO-STREAM), no attempt will be made to undo
any echoing of the character which might already have been done on
the stream. However, characters placed on the stream by UNREAD-CHAR
will be marked in such as way as to inhibit later re-echo by READ-CHAR.
Ammend the description of PEEK-CHAR to say that when the stream is
an echo stream (such as an interactive stream to the terminal or a
stream created by MAKE-ECHO-STREAM), characters which are only peeked
at are not echoed. Note however that in the case that the PEEK-TYPE
argument is not NIL, the characters which are passed by PEEK-CHAR
are treated as if by READ-CHAR, and so are echoed unless they have
been marked otherwise by READ-CHAR.
Ammend the description of streams to mention that interactive streams
to the terminal, such as the one held by *TERMINAL-IO*, have the same
rules for the time at which echoing must occur as do streams created
by READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Ammend the description of abstract input functions
READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
that they are implicitly affected by these new echoing rules of
READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Note: This is consistent with behavior [7] in the problem description.
Rationale:
Correct echoing behavior is important to programs which do batch
processing, parsing, etc. Allowing multiple or premature echoing
is clearly unsatisfactory.
The first proposal, PEEK-CHAR-READ-CHAR-ECHO:READ-CHAR, is in use
in a number of systems and is known not to cause much problem. I
suspect that the true reason it causes little problems, however,
is that people who care about echo behavior just avoid UNREAD-CHAR
as too unpredictable.
The second proposal, PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR, is
not in use in any particular system that I can name, though I
wouldn't be surprised to find a system which did it. It proposes
a more rational interpretation of the echoing behavior of
UNREAD-CHAR which might make it possible for programmers concerned
about echo behavior not to have to shy away from UNREAD-CHAR
altogether. (I also believe that this behavior will improve the
behavior of READ-PRESERVING-WHITESPACE with regard to echoing,
since it mentions using UNREAD-CHAR.)
I believe that either of these proposals is an improvement over
existing practice. The latter proposal I suspect is more
practically coherent though I unfortunately have only mental
exercises and no actual personal experience upon which to base
that belief.
Current Practice:
A wide variety of behaviors are in use.
Adoption Cost:
The code to implement the proposed change itself is probably fairly
localized.
In some operating systems, there may be echoing constraints which
I am overlooking. Depending on what those are, I may be
over-trivializing the difficulty of adopting these for some
implementations. I invite informed commentary on this issue.
In some cases, there may be second order effects in the system
itself which would also require a somewhat less predictable amount
of work to fix. In most cases, my hope is that the work would be
slight only because I assume that anyone who was going to rely on
a particular echo behavior for anything major would have realized
that CLtL wasn't guaranteeing this point and would have sent mail
complaining about this problem a lot sooner. Since no one has made
much noise about this, my hope is that it hasn't affected too many
people yet.
Benefits:
A number of applications involving of parsers, batch script
interpreters, and such would be possible to implement
straightforwardly and portably.
Conversion Cost:
My guess is that most users naively expect (perhaps even without
realizing it explicitly) that echoing will take care of itself.
Usually by this I think they expect that echoing will occur at
the time of the READ-CHAR. My hope is that most user code already
expects the proposed behavior. However, because of the fact that
READ, READ-LINE, etc.
Aesthetics:
These rules are intended to support the naive model that echoing
is the result of keyboard interaction and that each key struck
causes one character to echo. Users probably model file input as
batch keyboard input and expect analagous behavior. Because these
rules support that model, users will probably view this as a major
simplification and/or bug fix.
Discussion:
KMP supports PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR.
∂07-Mar-87 0006 RWK@yukon.scrc.symbolics.com IMPORTations into keyword package
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 00:06:28 PST
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by navajo.stanford.edu with TCP; Sat, 7 Mar 87 00:03:18 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175102; Sat 7-Mar-87 02:57:39 EST
Date: Sat, 7 Mar 87 02:57 EST
From: Robert W. Kerns <RWK@yukon.scrc.symbolics.com>
Subject: IMPORTations into keyword package
To: Jon L White <edsel!bhopal!jonl@navajo.stanford.edu>
Cc: navajo!Common-Lisp%sail@navajo.stanford.edu
In-Reply-To: <8703041559.AA01992@bhopal.edsel.com>
Message-Id: <870307025732.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Wed, 4 Mar 87 07:59:14 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Does anyone have a need/opinion about the meaning of importing an
"interned"symbol into the keyword package? ("interned" means already
"homed" in some package, such as Lisp or User). CLtL, page 175 strongly
suggests that "keywords" ought not to be imported into other packages
("keywords" means "present and owned by the keyword package"); but there
is no suggestion about the other direction.
Let's just make this "suggestion" symetric. I think this must have
just been assumed, given that "whenever a symbol is added to the
KEYWORD package the symbol is always made external; the
symbol is also automatically declared to be a constant (see DEFCONSTANT)
and made to have itself as its value."
∂07-Mar-87 1452 RPG Rob's Compiler Proposal
To: cl-cleanup@SAIL.STANFORD.EDU
I just now finished a quick reading of this proposal, and I am
not in a position to judge its soundness or the advisability of
its adoption. However, there were a few comments I have about it.
First, the correct running of a program can depend on such things
as the floating-point accuracy of the hardware. One imagines a
`correct' program on one computer converging while it diveges on
another. Rob's definition of portability seems to not address this
issue, though the language he uses indicates that he addresses all
portability issues.
Second, the transformation he mentions regarding replacing a DEFUN
with a LABELS implies a change in semantics of DEFUN or LABELS in
Common Lisp. I won't duplicate his precise example, but his example
implies that the following are equivalent:
(defun f (x) <body>)
(defun f (x) (labels ((f (x) <body>)) (f x)))
And, of coure, they aren't. If we want to change the semantics of
function-definition forms in Common Lisp (to which I might agree)
we should do that up-front rather than by sleazing it in during a
discussion of compilation semantics. Rob discusses a point related to
this one in an off-handed manner, but we should bring the discussion to
the fore.
Third, one of his example transformations for type declarations is
incorrect. He states that this function-type declaration:
(proclaim '(function fun (float) float))
implies the following transformation is legal:
(fun x) => (the float (fun (the float x)))
This isn't true, though it's a common misconception. The meaning of
the function-type declaration is approximately this English statement:
``If FUN is passed an argument of type FLOAT, it will return a value
of type FLOAT.''
On page 48 in CLtL, Steele notes that CONS is of type
(FUNCTION (FLOAT STRING) LIST)
I doubt we want this to happen:
(CONS X Y) => (THE LIST (CONS (THE FLOAT X) (THE STRING Y)))
I assume this proposal will be discussed further.
-rpg-
∂07-Mar-87 1544 jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK Re: evalhook, eval-when
Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 7 Mar 87 15:43:59 PST
Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06844; 7 Mar 87 23:41 WET
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Sat, 7 Mar 87 23:39:06 GMT
Message-Id: <3064.8703072339@aiva.ed.ac.uk>
To: johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK
Subject: Re: evalhook, eval-when
Cc: common-lisp@sail.stanford.edu
Date: Wednesday, 4 March 1987 15:57-EST
From: John Williams <johnw%cvaxa.sussex.ac.uk at Cs.Ucl.AC.UK>
[...] I'm tempted to leave *EVALHOOK* and friends out of my Lisp
(POPLOG Common Lisp) entirely, seeing as they are so obviously
interpreter-oriented, but then people use them in software that's
supposed to be portable, eg Portable Common Loops.
A key question here is whether Common Lisp requires that the environment
obtained via the &ENV parameter of a macro can meaningfully be passed to
EVALHOOK and vice-versa. This seems to be what's going on in things like
PCL. If this is allowed, then EVALHOOK still has a use of sorts even if
hook functions per se are never called. Of course, we might also ask
whether this *should* be allowed.
In any case, POPLOG Common Lisp might still have some use for hook
functions. While it would probably be going too far to compile a
check along with each form, it might make sense to check on function
calls. In some call implementations, this check could be in the
"link" routine and hence wouldn't mean compiling extra code. As
a user of POPLOG Common Lisp, I often wish there was a single stepper
of some sort, even if it didn't see forms "smaller than function calls".
Now for EVAL-WHEN. The problem here is that the concepts of COMPILE,
LOAD, and EVAL phases don't apply in an incrementally compiled Lisp -
POPLOG operates a READ-COMPILE-EXECUTE-PRINT loop, not a READ-EVAL-PRINT
loop. The only distinction that can be sensibly made is between having a
form evaluated 'now' (ie at the time the EVAL-WHEN form is processed) or
'in due course' (ie when it would have been executed in the normal
course of events).
Naively, I would expect the following interpretations of EVAL-WHEN
"times" in a "compiling EVAL" Common Lisp:
EVAL -- when a source file is being loaded.
LOAD -- when a compiled file is being loaded.
COMPILE -- when a file is being COMPILE-FILE'd
That is, the compilation that goes on whenever EVAL is called doesn't in
itself count as COMPILE-time. I think this means I agree with Moon --
this interpretation is the same as that for an "interpreting EVAL".
So, in addition to the distinction between 'now' and 'in due course', we
can distinguish between "'due course' means 'now'" (EVAL), and "'due
course' means 'later'" (LOAD/COMPILE).
From: Rob MacLachlan <RAM@edu.cmu.cs.c>
The rules for evaluation should exist independently of any
semantics of COMPILE-FILE.
While this seems right in general, the semantics of EVAL-WHEN might
well be considered part of the semantics of COMPILE-FILE.
The existence of COMPILER-LET, however, may cast doubt on the view that
"evaluation times" make sense in a "compiling EVAL" system (or, as a
consequence, in Common Lisp). If loading a source file is supposed to
obtain the interpreter-like interpretation (sorry for this word over-
loading), it seems that functions defined in this way and containing
calls to COMPILER-LET would have to have the binding of the special
variables in the COMPILER-LET put into their compiled code (as well
as being bound during their compilation) while this should not happen
if the functions were COMPILE-FILE'd.
-- Jeff
∂07-Mar-87 1559 RAM@C.CS.CMU.EDU Rob's Compiler Proposal
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 15:59:34 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sat 7 Mar 87 19:00:10-EST
Date: Sat, 7 Mar 1987 19:00 EST
Message-ID: <RAM.12284592137.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Rob's Compiler Proposal
In-reply-to: Msg of 7 Mar 1987 17:52-EST from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
Date: Saturday, 7 March 1987 17:52-EST
From: Dick Gabriel <RPG at SAIL.STANFORD.EDU>
To: cl-cleanup at SAIL.STANFORD.EDU
Re: Rob's Compiler Proposal
First, the correct running of a program can depend on such things
as the floating-point accuracy of the hardware. One imagines a
`correct' program on one computer converging while it diveges on
another. Rob's definition of portability seems to not address this
issue, though the language he uses indicates that he addresses all
portability issues.
Yep. It should certainly be made clear that this proposal does
not address all possible portability issues. The proposal concerns
itself with the range of legal implementation of evaluation, rather
than possible variations in the semantics of predefined functions and
types. Floating point is an especially ugly problem, since even
within a given implementation it is probable that the results will
vary between compiled and interpreted code, and even with different
compiler policies.
Second, the transformation he mentions regarding replacing a DEFUN
with a LABELS implies a change in semantics of DEFUN or LABELS in
Common Lisp. I won't duplicate his precise example, but his example
implies that the following are equivalent:
(defun f (x) <body>)
(defun f (x) (labels ((f (x) <body>)) (f x)))
And, of coure, they aren't. If we want to change the semantics of
function-definition forms in Common Lisp (to which I might agree)
we should do that up-front rather than by sleazing it in during a
discussion of compilation semantics. Rob discusses a point related to
this one in an off-handed manner, but we should bring the discussion to
the fore.
Yes. This is to some degree a packaging issue, since I have bundled
many separable proposals together into one document for my
convenience. There may be a nuance of my intention which was not
conveyed however. I don't claim that these two forms produce the same
result under all possible circumstances; I suggest that any program
that can tell the difference should be erroneous. The net result
would be that the two forms are "equivalent" as far as Common Lisp
programs are concerned.
Third, one of his example transformations for type declarations is
incorrect. He states that this function-type declaration:
(proclaim '(function fun (float) float))
implies the following transformation is legal:
(fun x) => (the float (fun (the float x)))
This isn't true, though it's a common misconception. The meaning of
the function-type declaration is approximately this English statement:
``If FUN is passed an argument of type FLOAT, it will return a value
of type FLOAT.''
If that is in fact what was intended, then I suggest that it be
changed before it is too late. That passage is pretty cryptic, but I
am not convinced that it supports your interpretation any better than
mine.
Rob
∂07-Mar-87 1614 RAM@C.CS.CMU.EDU evalhook, eval-when
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 16:14:28 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sat 7 Mar 87 19:14:17-EST
Date: Sat, 7 Mar 1987 19:14 EST
Message-ID: <RAM.12284594709.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK>
Cc: common-lisp@SAIL.STANFORD.EDU, johnw%cvaxa.sussex.ac.uk@CS.UCL.AC.UK
Subject: evalhook, eval-when
In-reply-to: Msg of 7 Mar 1987 18:39-EST from Jeff Dalton <jeff%aiva.edinburgh.ac.uk at Cs.Ucl.AC.UK>
Date: Saturday, 7 March 1987 18:39-EST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk at Cs.Ucl.AC.UK>
To: johnw%cvaxa.sussex.ac.uk at Cs.Ucl.AC.UK
cc: common-lisp at sail.stanford.edu
Re: evalhook, eval-when
A key question here is whether Common Lisp requires that the environment
obtained via the &ENV parameter of a macro can meaningfully be passed to
EVALHOOK and vice-versa.
The answer is no. See pp145-146 in CLTL in the discussion of the
(omitted) &environment keyword. I believe PCL is no longer doing
this, since it works on our system which uses a partial environment
for macroexpansion.
In any case, POPLOG Common Lisp might still have some use for hook
functions. [...] As a user of POPLOG Common Lisp, I often wish
there was a single stepper of some sort, even if it didn't see
forms "smaller than function calls".
Yes, evalhook is one way to implement a stepper. The question is
whether providing a portable way to implement steppers is so important
that we make life difficult for implementors by requiring it in Common
Lisp. There is nothing to stop compile-only implementations from
having steppers, but they probably aren't going to want to use
evalhook to do it.
Rob
∂07-Mar-87 1724 RPG Rob's Proposal etc
To: cl-cleanup@SAIL.STANFORD.EDU
Rob writes about LABELS versus DEFUN:
``I don't claim that these two forms produce the same
result under all possible circumstances; I suggest that any program
that can tell the difference should be erroneous.''
To clarify, he is proposing a change in semantics to DEFUN.
Rob writes about my `intepretation' of Common Lisp function type
specifiers:
``If that is in fact what was intended, then I suggest that it be
changed before it is too late. That passage is pretty cryptic, but I
am not convinced that it supports your interpretation any better than
mine.''
It is never too late to change something in Common Lisp.
One needs to look at pages 47 and 48 to understand type specifiers
for functions, and at pages 158 and 159 to understand how declarations
can use type specifiers.
The key passage is on page 47, where it says of the type specifier
(function (arg1-type arg2-type ...) value-type):
``Every element of this type is a function that accepts arguments *at*
*least* of the types specified by....''
The italics are Steele's emphasis. He goes on:
``As an example, the function CONS is of type (function (t t) cons),
because it can accept any two arguments and always returns a cons.
The function CONS is also of type (function (float string) list),
because it can certainly accept a floating-point number and a string
(among other things), and its result is always of type null....''
The passage isn't cryptic, but it is hard to understand, mainly, I think,
because it is saying something non-intuitive.
Linking together pages 47/48 and 158/159, we see we could declare
CONS as follows:
(proclaim '(ftype (function (float string) list) cons))
Whence, from Rob's proposed legal transformations we get
(CONS X Y) => (THE LIST (CONS (THE FLOAT X)(THE STRING Y)))
I'm totally convinced my interpretation is correct, and I am totally
convinced that Rob's is incorrect. I think Rob needs to revise his
proposal or propose a change to Common Lisp to accomodate his proposal.
-rpg-
∂07-Mar-87 1733 Moon@STONY-BROOK.SCRC.Symbolics.COM eval-when [former subject evalhook, eval-when]
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Mar 87 17:33:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87651; Sat 7-Mar-87 20:32:27 EST
Date: Sat, 7 Mar 87 20:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: eval-when [former subject evalhook, eval-when]
To: Rob MacLachlan <RAM@C.CS.CMU.EDU>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12284268851.BABYL@C.CS.CMU.EDU>
Message-ID: <870307203214.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 6 Mar 1987 13:24 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Now for EVAL-WHEN. The problem here is that the concepts of COMPILE,
LOAD, and EVAL phases don't apply in an incrementally compiled Lisp -
Yes, there are major problems with the specification of EVAL-WHEN.
The compiler cleanup committee is currently working on this, but we
probably can't offer a great deal of help since the only proposal that
deals with these problems advocates flushing EVAL-WHEN and replacing
it with new special forms.
Although Moon presumably knows the ancestral meaning of EVAL-WHEN,
In fact I was working from your proposal for the semantics of compilation
when I said what I said (of course keeping the name EVAL-WHEN since we're
discussing Common Lisp as it is today, not as it might be after it's
cleaned up in various ways). In other words, the distinctive thing about
COMPILE-FILE is early evaluation and late evaluation taking place in
different Lisp worlds, not anything about representation of programs as
executable machine instructions.
I
don't agree with his interpretation of it on the basis of dumping to
files. The rules for evaluation should exist independently of any
semantics of COMPILE-FILE.
In general that's true, but certainly the rules for evaluating EVAL-WHEN
are intimately connected with the semantics of COMPILE-FILE.
My current opinion that there are only three EVAL-WHEN situation
lists that can be used in portable code:
(compile load eval)
(load eval)
(compile eval)
The reason for this restriction is that other situation lists allow
programs to "tell the difference" between a compiled and an interpreted
implementation.
Given that only these situation lists are used, a compile-only system
can entirely ignore the EVAL situation, and interpret COMPILE as "do
it now" and LOAD as "do it eventually." In any situation where the
EVAL-WHEN body is not evaluated, the result of the EVAL-WHEN is NIL.
I agree with this, for a strong definition of "portable code" as code
that will execute identically in all implementations. A somewhat
weaker, but still extremely useful, definition of "portable code" as
code that will execute correctly in all implementations allows for
other situation lists. For example, (eval-when (compile) ...) is
a portable way to get a compile-time-only definition, in systems where
that concept is meaningful; programs that use this can be written in
such a way that they work correctly in all systems.
∂07-Mar-87 2004 RAM@C.CS.CMU.EDU FUNCTION type declaration
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Mar 87 20:04:00 PST
Received: ID <RAM@C.CS.CMU.EDU>; Sat 7 Mar 87 23:04:44-EST
Date: Sat, 7 Mar 1987 23:04 EST
Message-ID: <RAM.12284636668.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION type declaration
In-reply-to: Msg of 7 Mar 1987 20:24-EST from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
O.K. I'm perfectly happy to call this an incompatible change to
FUNCTION. I am curious how the current definition came about. What
are the advantages? I have been declaring the function types for all
the functions I have written in the past year, and have been using the
proposed strong interpretation of FUNCTION without any difficulties.
Current interpretation of the FUNCTION declaration:
If a function is called with the specified argument types, then it
will return the specified result type. It is legal to supply
other argument types; in this case the result type may be
different.
Proposed interpretation:
Same as above except that it is an error to supply arguments not
of the specified type.
The are three advantages to the proposed behavior for function type
declarations:
-- Argument types can be propagated down the tree as output type
assertions.
-- If there is a function type proclamation for a function, then
the type information can be propagated to the parameters of
definitions of that function.
-- Compiler warnings can be given for erroneous calls.
In contrast, it seems to me that the current function type declaration
is nearly useless. All it allows you to do is derive the result type
given that you can prove the arguments are of certain types. Under
the weak interpretation, it is basically a waste of time to declare
the argument types, since the system can't do anything with them.
Any type declaration
(function foo (type1 type2...) result)
could be more easily written:
(function foo * result)
thus saving both the compiler and the user lots of time. This assumes
that the result type isn't a function of the argument types, but when
this isn't true, the current interpretation isn't really any more
useful, since it only allows one type signature to be specified,
rather than a more general relationship (as would be needed for
functions such as +).
Rob
∂08-Mar-87 1206 RPG FUNCTION type declaration
∂08-Mar-87 1159 JAR@AI.AI.MIT.EDU FUNCTION type declaration
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87 11:59:06 PST
Date: Sun, 8 Mar 87 15:01:08 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: FUNCTION type declaration
To: RAM@C.CS.CMU.EDU
cc: KMP@AI.AI.MIT.EDU, RPG@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 7 Mar 1987 23:04 EST from Rob MacLachlan <RAM at C.CS.CMU.EDU>
Message-ID: <165214.870308.JAR@AI.AI.MIT.EDU>
You're playing with fire. Types are very hard to get right, and Common
Lisp is already confused enough. The FUNCTION subtyping rule at least
has the merit of being consistent with the other subtyping rules.
I think your change could perhaps be made to work, but you mustn't see
it as pertaining particularly to FUNCTION, since the properties of
FUNCTION are a necessary consequence of the concept of subtyping. The
change you suggest is really one to PROCLAIM, DECLARE, and THE; you want
to instruct the system to forget about any more specific type
information it might know about something when you do a proclamation.
[The type (function (t t) cons) is more specific than (function (float
integer) cons) because it's satisfied by fewer objects.] Then you want
to get a warning when the system can't verify that a use of the thing is
consistent with that more specific type.
If you make the change to FUNCTION types in isolation you run the risk
of having an inconsistent system. Ask yourself exactly what you're
instructing the system to do when you make a declaration: are you asking
it to trust you [e.g. to generate more efficient code], to complain when
it can show that a declaration is inconsistent, or to complain when a
declaration is unprovable? These three goals are rather at odds with
each other.
∂08-Mar-87 1324 RPG FUNCTION Type Declaration
To: cl-cleanup@SAIL.STANFORD.EDU
I just read JAR's remarks. I think that the main confusion in
the current CL type system is the silly type hierarchy we have in
place. My proposal for changing the specification of FUNCTION
is an attempt to remove part of the confusion.
Rob is attempting to clean up something else, and I'm simply
trying to make sure that any misunderstandings he has about
Common Lisp doesn't render his proposal untenable a priori.
Rob asked why the FUNCTION type specifier is as it is. I think the reason
is separation of concerns. In a well-designed language, there shouldn't
be a variety of ways to accomplish the same thing.
Consider as an example a function F that takes 1 argument and produces 1
value. The type declaration that narrows down the type of that argument
belongs with the definition of the function, because it is declaring the
type of a specific variable, namely the one that appear in the lambda-list
for the function F. Thus, this sort of declaration is of interest to the
compiler when it is compiling F.
The second sort of declaration concerns the point-of-call for an invocation
of F. The primary concern of the compiler is the result type of F. Presumably
the compiler has some idea about the type of the argument to F, and it wants to
know information of the form: If the argument I pass to F is of type T1, what
will the type of the value be?
One could argue that it might be helpful to know the type declaration of
the formal parameter to F in order to constrain, somehow, the type of the
actual parameter. But separation of concerns argues that we already have a
means of specifying that type, and the question becomes one of how to
tell the compiler about the definition of F.
I think Rob is proposing that we change the function type specifier to
effectively declare the types of the formal parameters instead of what it
currently does. If we do this we will have to invent another way to
provide the information that the compiler wants to know about invocations
of F.
For example, with the current situation one could declare as follows:
(defun f (x)
(declare (type t x))
...)
(proclaim '(function f (single-float) single-float))
(proclaim '(function f (fixnum) bignum))
(proclaim '(function f (cons) rational))
Clearly this would provide more information to the compiler about calls
to F than if we changed the function type specifier to also declare the
type of x.
-rpg-
∂08-Mar-87 1424 vanMelle.pa@Xerox.COM Does *read-suppress* suppress list construction?
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Mar 87 14:24:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 MAR 87 14:25:25 PST
Date: 8 Mar 87 14:23 PST
From: vanMelle.pa@Xerox.COM
Subject: Does *read-suppress* suppress list construction?
To: Common-Lisp@SAIL.Stanford.edu
Message-ID: <870308-142525-1326@Xerox>
What, if anything, does CLtL require of the value returned from read
when *read-suppress* is true? At a glance, I might assume that read
should perform all the gross syntactic work of parsing an input, without
creating symbols or causing errors, and return no meaningful result.
Surely the result cannot be very meaningful if all tokens are
uninterpreted.
Yet on p346 it says "Note that, no matter what the value of
*read-suppress*, parentheses still continue to delimit (and construct)
lists; the #( construction continues to delimit vectors; and comments,
strings, and the quote and backquote constructions continue to be
interpreted properly." This suggests that read must still return a list
structure where appropriate, even though it is full of nil tokens. I
tried
(let ((*read-suppress* t))
(read-from-string "(a b c)"))
in 3 implementations. Vax Lisp and 3600 return (nil nil nil). Lucid
returns nil.
It's hard for me to imagine any good reason to require read to return
anything meaningful when *read-suppress* is true. If it were required
to, it would inhibit an efficient use of *read-suppress* for programs
that simply want to skip over some input, even though they know (or
expect) the input is completely legal.
∂08-Mar-87 1428 FAHLMAN@C.CS.CMU.EDU PEEK-CHAR-READ-CHAR-ECHO
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87 14:27:53 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 8 Mar 87 17:28:25-EST
Date: Sun, 8 Mar 1987 17:28 EST
Message-ID: <FAHLMAN.12284837588.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PEEK-CHAR-READ-CHAR-ECHO
In-reply-to: Msg of 6 Mar 1987 16:49-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I agree in general with KMP's proposal that the behavior of echo streams
be spelled out, and that FIRST-READ-CHAR is the best model to follow.
There should be no problem in implementing this on any echo stream that
is unbuffered.
In an echo stream whose input side is buffered (linemode or whatever),
the data becomes available in a big lump, and then the Lisp system may
accept this input a character at a time. This proposal would in effect
require that the echoing in an echo stream must be done by READ-CHAR
itself, rather than by the lower-level machinery that collects and
delivers a line's worth of characters. That's OK with me, because our
system uses ECHO streams very rarely, but it might not be OK with
others.
One point that we want to be clear about is the following: *TERMINAL-IO*
might not be an echo stream or anything remotely resembling one. In CMU
Common Lisp, for example, there is a Hemlock top-level mode that allows
you to edit the input expression in an editor buffer, which of course
displays what you are doing; when you press the "do-it" button, a big
(possibly multiple-line) glob of input gets zapped to the Lisp as
"terminal" input. Obviously, any sort of echoing by the Lisp would be
inappropriate here.
So the parts of this proposal requiring "interactive streams...such as
the one held by *terminal-io*" to implement the echo-stream semantics
are too restrictive as they stand. I think it would be reasonable to
say that UNBUFFERED terminal interaction should attempt to mimic the
behavior specified here for echo streams.
One final point: "amend" is spelled with only one #\m.
-- Scott
∂08-Mar-87 1448 FAHLMAN@C.CS.CMU.EDU SHARPSIGN-PLUS-MINUS-PACKAGE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87 14:48:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 8 Mar 87 17:49:12-EST
Date: Sun, 8 Mar 1987 17:49 EST
Message-ID: <FAHLMAN.12284841369.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE
In-reply-to: Msg of 1 Mar 1987 17:35-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I support SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD.
I'd like to see a revised version, clarifying exactly what KMP and MOON
have decided should happen in the case of non-existent packages and
non-exported symbols. I agree in general with the view that read errors
that occur within a #+ or #- should be treated as "feature not present".
I was going to ask what it means for a package such as SYSTEM to be
"locked" in the Symbolics system, but I suspect that I'd rather not
know. Sounds like Ada-stuff.
-- Scott
∂08-Mar-87 1456 FAHLMAN@C.CS.CMU.EDU SHARPSIGN-PLUS-MINUS-NUMBER
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87 14:56:36 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 8 Mar 87 17:57:11-EST
Date: Sun, 8 Mar 1987 17:57 EST
Message-ID: <FAHLMAN.12284842825.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: SHARPSIGN-PLUS-MINUS-NUMBER
In-reply-to: Msg of 1 Mar 1987 17:37-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
I somewhat reluctantly support this proposal.
I think that it's lousy style to use a bare number as a feature -- I
know what Symbolics-3600 or SYMBOLICS:3600 means, but reasonable people
might disagree on what 3600 means. I'm tempted to rush to the registrar
(if we had one) and grab all the good numbers in advance: 1, 2, 666...
But in this case, since it is a portability issue and numbers are OK in
some other Lisps, I'm willing to go with the flow. Did we ever decide
what should happen with potential numbers?
-- Scott
∂08-Mar-87 1516 Moon@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Mar 87 15:16:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87851; Sun 8-Mar-87 18:09:13 EST
Date: Sun, 8 Mar 87 18:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12284841369.BABYL@C.CS.CMU.EDU>
Message-ID: <870308180900.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 8 Mar 1987 17:49 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I was going to ask what it means for a package such as SYSTEM to be
"locked" in the Symbolics system, but I suspect that I'd rather not
know. Sounds like Ada-stuff.
I don't know why Kent phrased it that way; maybe because an error message
that should have been rewritten in English phrased it that way.
At least for purposes of this discussion it means that the package
behaves according to the way CLtL says packages should behave, rather
than some other way that Symbolics also supports. Specifically,
reading the syntax FOO:BAR (one colon) signals an error unless BAR has
been exported from FOO.
∂08-Mar-87 2153 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87 21:53:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 00:53:51-EST
Date: Mon, 9 Mar 1987 00:53 EST
Message-ID: <FAHLMAN.12284918673.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: fahlman@C.CS.CMU.EDU
Subject: FUNCTION-TYPE
I'd like to discuss a bunch of issues raised by RPG's FUNCTION-TYPE
proposal. I think that we need to understand some of these issues
better and see if we can reach a consensus before we try to produce a
final proposal (or set of proposals) to bring before the community.
I should say first of all that, speaking only for myself, I would favor
all of RPG's proposed changes (if I understand them correctly).
However, I think that his proposal contains some lines of argument that
might hurt his cause, and it bundles issues together in a way that many
people will view as unfair: a proposal for the obviously necessary
cleanup of the FUNCTION data type is combined with some incompatible
changes whose justification is more aesthetic than anything else.
Companies for whom incompatible changes are very expensive might want to
accept the cleanup but not the rest of the proposal. It is unfair of us
to try to "sleaze" these changes past them by mixing everything
together and then telling them to take it or leave it.
As I understand RPG's proposal (as clarified by subsequent discussion),
it suggests the following incompatible changes:
1. A change in the definition of the FUNCTION type (and of FUNCTIONP, if
we keep it). Symbols, whether or not fboundp, and lambda expressions
would no longer qualify as functions. We are left with compiled
function objects and interpreted closures.
2. It "is an error" to put anything other than a function (new strict
definition) into the SYMBOL-FUNCTION cell. Implementations may put
other things there if they choose, but portable code cannot count on
this. Actually, this is unclear at present, so it counts as a
clarification and not a change. FUNCTION when called on a symbol would
return the associated function if there is one; if the symbol currently
names a macro or special form, FUNCTION signals an error, regardless of
what might be in the SYMBOL-FUNCTION cell.
3. The FUNCTION data type must be disjoint from the CONS data type.
This underlines the requirement that a lambda expression is not a type,
but it goes farther: it prohibits implementors from using a list to
implement any of the FUNCTION subtypes. I suspect that a majority of
implementations currently use lists to implement functions in the
interpreter, so this is not just a hypothetical incompatibility.
4. The functional argument to FUNCALL, APPLY, and friends must now be a
function (strict definition). It may not be a lambda expression or a
symbol naming a function, thought this is clearly legal at present.
One could quibble about whether the FUNCTION type is "bankrupt" or just
a mess, but I agree that change 1 or something close to it is the right
way to perform the needed cleanup. Change 2 is probably not too
controversial.
I asked in an earlier note about change 3, forbidding the use of a list
to implement functions. Some of RPG's reply strikes me as bogus. He
says that lists and functions are conceptually distinct, just as numbers
and lists are distinct. In my own view, lists are perfectly good raw
material from which to implement other data types that (functionally)
have nothing to do with lists. It is analogous to the use of a vector
to implement a named structure that in turn implements a random seed or
a window. (Currently we have a more awkward situation that really is
untenable: FUNCTION and CONS overlap, but neither type contains the
other and we don't have a clean predicate for the itnersection.)
But despite this objection that one of the arguments is weak, I agree
with some of the other reasons for making FUNCTION and CONS be disjoint
types: it prevents any further confusion about whether a Lambda list is
a function, and it cleans up the type hierarchy in a way that should
make the new object proposal less complex. And we are moving away from
the position that it is OK to implement a structure (or an instance) as
a Lisp vector.
Change 4 is perhaps the one that affects the most user code, and it is
the change whose motivation is weakest. One could imagine (and Moon has
proposed) adopting all the other changes, but saying that FUNCALL, APPLY
and friends can take a function (new definition), a lambda list, or a
symbol: in the latter two cases, FUNCTION is applied to the argument
before it is used. RPG asserts that he likes his original proposal
better. So do I, on aesthetic grounds, but I think we need more
ammunition than that in order to propose an incompatible change of this
size to the user community. Is there a better justification? If not, I
think we should not push this change, or at least we should make it a
separate issue.
Some other points:
I think that RPG's proposed new definition of the function type is
circular, or at least not very easy to understand: "A FUNCTION is
anything that might legally be given to FUNCALL or APPLY...and is to be
executed as code." I think we need to nail this down by spelling out
all the cases in one place, when the FUNCTION data type is being
defined.
I don't like Moon's proposal that we flush FUNCTIONP. I think that lots
of people will view this as a gratuitous incompatibility. We need to
clean up the definition of the FUNCTION data type, so that (TYPEP ...
'FUNCTION) means something. Once we've done that, I think we should
just define FUNCTIONP to mean the same thing as (TYPEP ... 'FUNCTION).
At some point, we should consider whether to add new mumble-P predicates
for all of the basic types or to get rid of them all, but I see no good
reason to add or delete any except as part of such a systematic change.
It is a very bad idea to say that an advantage of the proposed change is
that "it is the first step towards a Lisp1-ification of Common Lisp". A
lot of people would vote against the FUNCTION-TYPE proposal if they
believed that. I might be one of them -- I'm against any such steps
until I see a workable Macro proposal. Just say that it brings us
closer to Scheme and let it go at that. In truth, I don't think that
this has much to do with the Lisp1/Lisp2 issue per se.
What exactly do we say that the FUNCTION special form does? How about
the following: If applied to a symbol, it returns the current functional
definition, if any, else it signals an "undefined" error. (An error is
signalled if the symbol currently names a macro or special form instead
of a function.) If applied to a lambda expression, FUNCTION returns a
function corresponding to the closure of that lambda expression in the
current lexical environment. If applied to a function, it returns that
function unchanged. Else it signals a "wrong type arg" error. [I guess
we shouldn't use the verb "apply" with a special form, but you get the
idea.]
We should fix the description of DEFUN to make it clear that it is
equivalent to
(SETF (SYMBOL-FUNCTION name)
(FUNCTION (LAMBDA ...)))
That is, the closure of the lambda in the environment of the defun is
what gets saved.
Do we want to propose that Lambda is a special form (or special
operator), and that when you execute a lambda expression it returns the
closure, just as (FUNCTION (LAMBDA ...)) does now? That looks OK to me.
Under the definition of FUNCTION above, the (FUNCTION (LAMBDA ...)) form
would be allowed, so this introduces no new compatibility problems.
Probably we should explicitly name COMPILED-FUNCTION and
INTERPRETED-FUNCTION as subtypes of FUNCTION, and make TYPEP work for
them. Am I correct in deducing that there would be no such thing as a
function that is not closed in some environment -- possibly the null
environment? Moon seems to think that interpreted functions and
interpreted closures would be distinct concepts. Some implementations
currently use the raw lambda expression to represent functions whose
closure doesn't capture anything external, but this would no longer be
legal.
That's all for now. I might add that Rob independently came up with the
objection about all this stuff being bundled. So, with Moon, that's
three of us who found this aspect of the proposal to be troubling.
-- Scott
∂08-Mar-87 2351 RPG Scott's Remarks on FUNCTION Type
To: cl-cleanup@SAIL.STANFORD.EDU
Scott has some good points. I include here some other clarifying
remarks. Once we agree on a rational proposal, I will write it
up.
Scott writes:
``Some of RPG's reply strikes me as bogus. He says that lists and
functions are conceptually distinct, just as numbers and lists are
distinct. In my own view, lists are perfectly good raw....''
[This quote is not intended to imply that Scott enjoys lists the way
someone might enjoy sushi: it was an accident of editing.]
My point was that lists and functions must be disjoint, because it
makes no sense to take CAR of a function, whereas it might make sense
to take CAR of an expression. Because we cannot conceive of doing
(CAR 99), we made LIST, CONS, and NUMBER disjoint. Similarly,
(CAR #'(LAMBDA (X)(+ X X))) strikes me as nonsense.
Scott writes:
``It is analogous to the use of a vector to implement a named structure
that in turn implements a random seed or a window.''
Alas, we cannot eliminate all puns from the language. I asked a
user interface guy what it meant to take VREF of a window, and he
got confused. But we cannot expect all implementations to separate
all types, so I agree with his point vis-a-vis the current Common Lisp
world situation.
Scott writes:
``One could imagine (and Moon has proposed) adopting all the other
changes, but saying that FUNCALL, APPLY and friends can take a function
(new definition), a lambda list, or a symbol: in the latter two cases,
FUNCTION is applied to the argument before it is used.''
Another alternative would be to define a functional form of FUNCTION,
called, for argument's sake, ENSURE-FUNCTION, such that
(ENSURE-FUNCTION <lambda-form>) = <closure corresponding to lambda-form>
(ENSURE-FUNCTION <symbol>) = (SYMBOL-FUNCTION <symbol>)
(ENSURE-FUNCTION <function>) = <function>
and then to define FUNCALL and APPLY to apply ENSURE-FUNCTION on its
first argument. It would be nice to see how the `purist' proposal
would fly before springing it on the world. I believe there is
a lot of code that would break if we added the purist proposal.
Scott writes:
``I think that RPG's proposed new definition of the function type is
circular, or at least not very easy to understand: ....''
I simply removed text from section 2.13. I believe the text I removed
didn't clarify this circular definition. I'm not sure how much more
precisely we define function in CLtL except by providing a denotational
semantics for Common Lisp. Or maybe some examples of turning lambda-expressions
into functions would help.
Scott writes:
``It is a very bad idea to say that an advantage of the proposed change is
that "it is the first step towards a Lisp1-ification of Common Lisp". ''
I agree it might be impolitic.
Scott writes:
``Do we want to propose that Lambda is a special form (or special
operator), and that when you execute a lambda expression it returns the
closure, just as (FUNCTION (LAMBDA ...)) does now?''
I would agree with this.
Scott writes:
``Probably we should explicitly name COMPILED-FUNCTION and
INTERPRETED-FUNCTION as subtypes of FUNCTION, and make TYPEP work for
them.''
Possibly these should not be required to be pairwise disjoint (?).
I think we shouldn't presume that all implementations implement
functions as closures. I can imagine an implementation with
COMPILED-FUNCTIONs, INTERPRETED-FUNCTIONs, COMPILED-CLOSUREs,
and INTERPRETED-CLOSUREs.
-rpg-
∂09-Mar-87 0802 FAHLMAN@C.CS.CMU.EDU Scott's Remarks on FUNCTION Type
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87 08:01:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 10:57:49-EST
Date: Mon, 9 Mar 1987 10:57 EST
Message-ID: <FAHLMAN.12285028625.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Scott's Remarks on FUNCTION Type
In-reply-to: Msg of 9 Mar 1987 02:51-EST from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
My point was that lists and functions must be disjoint, because it
makes no sense to take CAR of a function, whereas it might make sense
to take CAR of an expression. Because we cannot conceive of doing
(CAR 99), we made LIST, CONS, and NUMBER disjoint. Similarly,
(CAR #'(LAMBDA (X)(+ X X))) strikes me as nonsense.
Well, I don't derive "must be disjoint" from this argument. I would
agree with "can be disjoint" and maybe "should be disjoint, since
non-disjointness buys the users nothing and is likely to confuse them".
Since I agree with the split on other grounds, I mention this only
because I think this this argument will strike some people as a weak
one, so we should not rely too heavily on its persuasive power in the
coming debate.
Another alternative would be to define a functional form of FUNCTION,
called, for argument's sake, ENSURE-FUNCTION, such that
(ENSURE-FUNCTION <lambda-form>) = <closure corresponding to lambda-form>
(ENSURE-FUNCTION <symbol>) = (SYMBOL-FUNCTION <symbol>)
(ENSURE-FUNCTION <function>) = <function>
and then to define FUNCALL and APPLY to apply ENSURE-FUNCTION on its
first argument.
Yeah, this might be the right move. The FUNCTION special form now
becomes pretty useless, but we have to keep it for compatibility.
On the issue of how we define the function type, I'm not arguing that we
need a denotational semantics. I just think that we ought to spell out
the various types of functions and where they come from (compilation,
closing a lambda expression, etc.) rather than relying on some formula
like "executed as code". Not a big deal, but the less we leave to the
user's imagination, the smaller the chances that we'll be doing this
again a year from now.
Scott writes:
``Probably we should explicitly name COMPILED-FUNCTION and
INTERPRETED-FUNCTION as subtypes of FUNCTION, and make TYPEP work for
them.''
Possibly these should not be required to be pairwise disjoint (?).
Well, these make sense only in systems that do support both compiled and
interpreted code. In compiler-only or interpreter-only systems, I guess
the best move would be to say that every function is a member of both of
these subtypes: it is both a fast function and a slow function.
I think we shouldn't presume that all implementations implement
functions as closures. I can imagine an implementation with
COMPILED-FUNCTIONs, INTERPRETED-FUNCTIONs, COMPILED-CLOSUREs,
and INTERPRETED-CLOSUREs.
Now you're the one who is letting the user see internal stuff that is
none of his concern. All of these functions are closures, in that they
no longer have any free variables waiting to be closed. In some cases,
there may have been none in the first place, and implementors may want
to use some efficient internal form in such cases, but is there any
reason the user needs to know that? A confusing concept that does him
no good (I think).
-- Scott
∂09-Mar-87 0832 gls@Think.COM FUNCTION type declaration
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 9 Mar 87 08:32:09 PST
Received: from thorlac by Think.COM via CHAOS; Mon, 9 Mar 87 11:32:49 EST
Date: Mon, 9 Mar 87 11:32 EST
From: Guy Steele <gls@Think.COM>
Subject: FUNCTION type declaration
To: RAM@c.cs.cmu.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <RAM.12284636668.BABYL@C.CS.CMU.EDU>
Message-Id: <870309113258.2.GLS@THORLAC.THINK.COM>
Consider declaring the type of INTEGRATE, declared as follows:
(defun integrate (fn low high step)
(if (>= low high) 0.0
(+ (* step (funcall fn (+ low (/ step 2))))
(integrate fn (+ low step) high step))))
This is not the world's best integrator, of course, but that
isn't the point, which is: what are the types of the parameters?
Clearly we may have
(declare (type (or float rational) low high step))
As for fn, we must have a function that, when given an argument
that is a float or rational, produces a float or rational:
(declare (type (function ((or float rational)) (or float rational)) fn))
Thus we have:
(defun integrate (fn low high step)
(declare (type (function ((or float rational)) (or float rational)) fn))
(declare (type (or float rational) low high step))
(if (>= low high) 0.0
(+ (* step (funcall fn (+ low (/ step 2)))
(integrate fn (+ low step) high step))))
Now suppose that we wanted to integrate the function f(x)=x.
An obvious thing to try is (INTEGRATE #'IDENTITY 0 1 .01)
(On a Symbolics 3600 this produces 0.51004976 as the result.
I told you this was not the world's greatest integrating function.)
Under the current interpretation, IDENTITY is a valid argument
to INTEGRATE because *if* given a rational or float it produces
a rational or float. Under the interpretation Rob proposes
IDENTITY would not be a valid argument, because it accepts
arguments other than floats and rationals. It would be necessary
to define a new function
(defun fr-identity (x) (declare (type (or float rational) x)) x)
This would be a valid argument to INTEGRATE, whereas
(defun fr-identity (x) x)
would not be valid.
Rob's interpretation leads to the curious conclusion that a program can
become invalid by *removing* declarations. This is contrary to the
intent that a Common Lisp program does not require type declarations to
be correct. I agree that a program can become incorrect by *adding*
incorrect declarations, but I think we don't want a situation where a
correct program can become incorrect by *removing* a correct declaration
(other than SPECIAL).
I am sympathetic to the notion that it is desirable to have a way to
specify required types of function arguments. However, I agree with RPG
that simply changing the current interpretation of the FUNCTION declaration
will not do.
--Guy
∂09-Mar-87 1119 RPG Scott's Remarks and Other Important Matters
To: cl-cleanup@SAIL.STANFORD.EDU
Modulo some minor misunderstandings about the strengths of arguments and
what we mean when we make various statements, I think Scott and I are in
agreement. Does anyone else have comments?
If we intend to meet next Sunday, we should make a plan. Xerox is near the
X3J13 hotel. If Larry will volunteer to host us, I will swing by the hotel
to take or lead people over to PARC. If Larry cannot do it, I can find a
place to meet - Stanford is the next closest place I have access to.
I suggest that we plan to meet at the registration desk at 2pm Sunday for
a 2-3 hour meeting.
-rpg-
∂09-Mar-87 1138 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-NUMBER (revision 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Mar 87 11:35:35 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88417; Mon 9-Mar-87 14:35:29 EST
Date: Mon, 9 Mar 87 14:34 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-NUMBER (revision 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870301173706.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<FAHLMAN.12284842825.BABYL@C.CS.CMU.EDU>,
<870303121816.2.GLS@BOETHIUS.THINK.COM>,
<870303140437.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870309143446.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SHARPSIGN-PLUS-MINUS-NUMBER
References: #+ (p358), #- (p359), *features* (p448),
Parsing of Numbers and Symbols (p339-342)
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 03/01/87,
Revision 2 by KMP 03/09/87 (address potential numbers)
Problem Description:
Features which are not symbols are currently not allowed.
Unfortunately, machine names are desirable as features. Since
some machines are named only by a number (eg, 360, 3600, 8600,
8080, ...) there is no way to use these names as features.
Alternate, less mnemonic feature names, must be contrived.
`Potential numbers' (as described on p341) should be addressed
specifically if only to say that they are still illegal. There
should be no ambiguity about what is legal and what is not.
An example of such a symbol is 68020A .
Proposal (SHARPSIGN-PLUS-MINUS-NUMBER:OK)
Extend the definition of #+ and #- on pp358-359 to say that
integers are allowable as features. Define that the feature-spec
reader binds base to 10 so that people don't have to do #+7020 to
find the 3600 feature in base 8.
In the case of `potential numbers' (as per p341) in a feature
spec, say that they are allowed for use in this context. If the
implementation does not support the syntax in question, it is
permitted to treat the syntax as if it denoted a feature which
was known not to be present. That is, in any implementation where
a potential number which is denoted by a character sequence <X> can
be parsed by the reader as either a number or a symbol, then
#+<X> will skip the next form iff the expression
(MEMBER (LET ((*READ-BASE* 10.)
(*PACKAGE* (FIND-PACKAGE "KEYWORD")))
(READ-FROM-STRING "<X>"))
*FEATURES*)
yields false, without prejudice to decision about whether <X>
denotes a number or a symbol. If <X> cannot be read by the reader
because it is a potential number, then #+<X> will skip the next
form as if any feature <X> might have been intended to denote was
not present.
[We also need to nail down the rules for what package is used in
the feature-spec reader. I've put that in a separate proposal.]
Extend the definition of *features* on p448 to say that it is a
"list of symbols and/or numbers".
Rationale:
There is no deep-rooted reason why numbers shouldn't work.
The current restrictions are somewhat arbitrary. This would
allow arbitrary alphanumeric strings (subject to restrictions
about potential numbers) to be used as identifiers in a
well-defined way.
Current Practice:
Some implementations already allow this (though most probably
do not bind base to 10 -- I've seen some octal feature names).
Other implementations signal an error if they see what they
believe to be an invalid feature name (such as a number).
Adoption Cost:
Changes to implementations not already supporting this feature
would probably be very minor.
Benefits:
A restriction which seems arbitrary to some people would be removed.
Conversion Cost:
Some users would view this as an enhancement; others as a bug fix.
I don't think it would be seen in a negative light.
Aesthetics:
No issues not already addressed above.
Discussion:
KMP initiated this proposal and thinks that it would be a
worthwhile extension.
Steele asks about treatment of potential numbers, such as #+68020a .
Revision 2 of this proposal addresses that issue, by explicitly
stating that this is allowed.
Fahlman reluctantly supported version 1 of this proposal since
some implementations support numbers here and since the purpose of
this feature is to allow selection of such implementations. He
wishes people would write Symbolics-3600 rather than 3600 since it
isn't clear that 3600 is meaningful in the abstract. He wants to
see the potential number issue treated, however.
KMP thinks that the problem of meaningfulness is not unique
to numbers. Many feature names with only alphabetic characters
could be likewise criticized. In practice, brevity is important
because AND and OR will greatly increase horizontal size of
feature-spec expressions and often it's desirable to still have
enough room to the right to grind the conditionalized expression.
∂09-Mar-87 1152 Masinter.pa@Xerox.COM Cleanup committee meeting at PARC, Sunday 2 PM
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Mar 87 11:52:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 MAR 87 11:36:16 PST
Date: 9 Mar 87 11:39 PST
From: Masinter.pa@Xerox.COM
Subject: Cleanup committee meeting at PARC, Sunday 2 PM
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 09 Mar 87
11:19 PST
To: RPG@SAIL.STANFORD.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870309-113616-2074@Xerox>
Why don't you meet early enough to be here (at PARC) 2. I've already
been planning for a meeting room, although I'd like to know how many
people will be coming. (So far, I've only heard from Fahlman, Gabriel,
and Pitman.)
Agenda: I'd like to make sure we get those things for which there is
apparent consensus out of the way first (for one hour), and talk about
a strategy for handling issues file (for an hour). Then we can get to
things like the compiler proposal.
There have been a couple of proposals for which amendments were proposed
and (apparently) accepted. It would help if those involved could put
together an updated version of the proposal which includes the
amendment.
I'm working on, and will send out in the next couple of days, a list of
the issues submitted along with my belief as to their status.
∂09-Mar-87 1204 KMP@STONY-BROOK.SCRC.Symbolics.COM SHARPSIGN-PLUS-MINUS-PACKAGE (revision 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Mar 87 12:03:49 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88466; Mon 9-Mar-87 15:04:00 EST
Date: Mon, 9 Mar 87 15:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SHARPSIGN-PLUS-MINUS-PACKAGE (revision 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870308180900.5.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<FAHLMAN.12284841369.BABYL@C.CS.CMU.EDU>,
<870303200935.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<870303145255.4.GLS@BOETHIUS.THINK.COM>,
<870303125939.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<870303114830.1.GLS@BOETHIUS.THINK.COM>,
<870303020058.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<870303003144.0.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<870301173547.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870309150315.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: SHARPSIGN-PLUS-MINUS-PACKAGE
References: #+ (p358), #- (p359), *features* (p448)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 03/01/87,
Revision 2 by KMP 03/09/87 (clarify package errors)
Problem Description:
No information is provided in the description of #+ and
#- (pp358-359) about what package the features are read on.
In some systems, the current package is used. Since there
is no wording to the contrary, it's reasonable to assume that
this would be done, but a consequence of this is that you
must be much more sensitive to the package you're in at any
given time when using #+ or #- even for system-provided
features. (This will be a big problem if we decide to require
that the LISP package can contain only the symbols in CLtL
because system-provided features will likely not have the
names of symbols on LISP and hence will require package
prefixes. Having a symbol named LISP:SYMBOLICS or LISP:LUCID
would not be possible, so something like #+Symbolics would
not be possible; you'd have to write #+SYSTEM:SYMBOLICS or
some such, which might get a read error in a non-Symbolics
implementation that didn't export SYMBOLICS from SYSTEM...)
In some systems, a canonical package (such as KEYWORD) is
used. This means that package prefixes are rarely necessary
in sharpsign conditionals for system-provided features
regardless of the current package or restrictions about what
may be in LISP. (For example, the KEYWORD package can have
any symbol so it's not a problem to push :SYMBOLICS or :LUCID
on *FEATURES*).
This has implications about what goes on the *FEATURES*
list (p448).
Voting Notes:
Choose only one of these proposals.
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD):
Change the wording on pp358-359 so that it says that the
default package while reading feature specs is the keyword
package. Emphasize that other packages may be designated by
use of explicit package prefixes.
Add slightly redundant wording on page 448 to emphasize
that the symbols on *FEATURES* may be in any package but
that in practice they will mostly be on the keyword package
because that's the package #+/#- uses by default. If symbols
in a package other than keyword appear on *FEATURES*, they
will be seen by #+/#- only if marked by explicit package
prefixes in the written feature-spec.
Clarify that the package of the IEEE-FLOATING-POINT symbol
mentioned on p448 is KEYWORD.
Define that while reading the feature spec, no read error
will be signalled if reference is made to a symbol on a
non-existent package or an external reference is made to
a symbol in a package which does not export that symbol.
Instead, the behavior shall be as if a symbol was named
which was not present on *FEATURES*. For example,
#+LISP:NOT-EXPORTED and #+#:NOT-EXPORTED are treated
equivalently -- each reads and discards the subsequent form.
Proposal (SHARPSIGN-PLUS-MINUS-PACKAGE:CURRENT):
Change the wording on pp358-359 so that it says that the
current package is used to read feature specs.
Add redundant wording on page 448 to emphasize that the
symbols on *FEATURES* may be in more than one package and
that #+/#- will read symbols in the current package and
use EQL to search *FEATURES*.
Clarify that the package of the IEEE-FLOATING-POINT symbol
mentioned on p448 is LISP.
Define that while reading the feature spec, no read error
will be signalled if reference is made to a symbol on a
non-existent package or an external reference is made to
a symbol in a package which does not export that symbol.
Instead, the behavior shall be as if a symbol was named
which was not present on *FEATURES*. For example,
#+LISP:NOT-EXPORTED and #+#:NOT-EXPORTED are treated
equivalently -- each reads and discards the subsequent form.
Rationale:
Since it's clear that Common Lisp is not going to handle all
of everyone's needs, one of the most important things we can
provide is a well-defined conditionalization system to allow
people to escape to native code where Common Lisp is deemed
inadequate.
Current Practice:
Some implementations bind *PACKAGE* while reading feature
specs and others do not.
Adoption Cost:
Changes to implementations to make them conform to either
of these should be fairly minor if not trivial.
Benefits:
#+/#- are not currently very portable. As such, there's
almost a bootstrapping problem where you need to #+/#-
conditionalize the setup of features since different systems
take them in different ways. Either of these changes would
make #+/#- work in a more portable way.
Conversion Cost:
Code which is implementation-conditionalized enough for this
to make a difference may require some changes. Even if those
changes turned out not to be completely trivial, my guess
from past experience in my own code is that maintainers of
such code would happily pay the cost of such changes in order
to have something which is more regular and predictably portable.
Aesthetics:
Most users would perceive this as a bug fix either to CLtL
or to certain implementations.
Discussion:
KMP thinks that nailing this down as soon as possible
is essential.
KMP's strong preference is for SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD.
Even if KEYWORD were chosen as the default package for
system-supplied symbols, it would be quite reasonable to
suggest that only vendors should add keyword symbols to
the *features* list, suggesting that users should add
features on their personal packages so that collisions due
to user applications were less likely. This idea might be
a subject of controversy though, so is definitely not part
of the proposal currently up for consideration.
Moon asked what should happen with symbols in non-existent
packages and symbols in existing packages that are referenced
as if external but which are not external. After some
discussion between KMP and Moon, it was agreed that the only
rational interpretation of this is that `there exists some
implementation somewhere in which this symbol reference is
valid, and other implementations should treat this as a
missing feature without complaining about read syntax.'
Steele and Fahlman expressed support for version 1 of the
SHARPSIGN-PLUS-MINUS-PACKAGE:KEYWORD.
∂09-Mar-87 1342 KMP@STONY-BROOK.SCRC.Symbolics.COM PEEK-CHAR-READ-CHAR-ECHO
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Mar 87 13:41:55 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88626; Mon 9-Mar-87 16:41:26 EST
Date: Mon, 9 Mar 87 16:40 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PEEK-CHAR-READ-CHAR-ECHO
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12284837588.BABYL@C.CS.CMU.EDU>
Message-ID: <870309164039.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Well, I'm going to ramble here about interactive streams a bit, but I
want to make it clear up front that it's still very important to me that
we standardize on echo streams even if we don't end up agreeing on
interactive streams.
One of the problems with some buffering strategies is that some user
programs that don't expect buffering don't work well within them.
What I really want is for input and output to be reliably synchronized
and as I understand it, the strategy you say Hemlock uses is working
against that goal.
For the sake of example, let's consider the following portable program:
(DEFUN SQRT-SYSTEM ()
(DO ((VALUE (PROGN (FORMAT T "~&Number: ") (READ))
(PROGN (FORMAT T "~&Number: ") (READ))))
((NOT VALUE))
(FORMAT T "~&~S~%" (SQRT VALUE))))
It seems to me that a lot safer way for your Hemlock interface to work
is to keep input conceptually separate from program output (which would
include echoing) and then whenever you type anything, it would put that
stuff in the program's input buffer (removing it from the buffer you
were just editing) and let it be re-echoed by the program. That way,
you could do things like:
Lisp> (SQRT-SYSTEM)<Do-It>
Number: 4 9 16<Do-It>
and see (#1):
Lisp> (SQRT-SYSTEM)
Number: 4
2
Number: 9
3
Number: 16
4
Number:
If instead you say that buffered streams should not echo and that the
original input should be left in place, the typical program behavior
of (#2) looks like:
Lisp> (SQRT-SYSTEM)
Number: 4 9 16
2
Number:
3
Number:
4
Number:
Of course, you could always write something that did:
(DEFUN SQRT-SYSTEM ()
(DO ((VALUE (PROGN (IF (NOT (LISTEN)) (FORMAT T "~&Number: ")) (READ))
(PROGN (IF (NOT (LISTEN)) (FORMAT T "~&Number: ")) (READ))))
((NOT VALUE))
(PRINT (SQRT VALUE))))
and then you'd see the following (#3) in you non-echoing buffered system:
Lisp> (SQRT-SYSTEM)
Number: 4 9 16<Do-It>
2
3
4
Number:
This looks nice but it's a lot of pressure to put on users to say that they
should always remember to use LISTEN before prompting. Users who don't use
systems which do this kind of buffering are going to wonder why they should
have to think about this.
Obviously in some cases such as those involving printing terminals or
low-level line-at-a-time buffering which cannot be controlled, we'll have
no choice but to allow *TERMINAL-IO* to be an unbuffered stream upon which
no echo occurs, but I think that this should be by way of `tolerance' of
things beyond our control and should not be the user interaction model that
we want users to think in terms of. Maybe I'm being chauvanistic, though.
I looked at the Apollo and was very surprised to find that Lucid
(apparently) doesn't share my view. Perhaps they're just using tools
that are supplied by the Apollo -- I don't know how the modularity
works, but it seems to me (admittedly not a sophisticated Apollo user)
that the prompt should live only in the display window, that text in the
input pad should contain only characters to be stuffed to the input
stream, and that characters which get stuffed should be echoed in the
display area by the program at the time of READ-CHAR rather than being
echoed by the system at the time of window-to-window paste and not
further echoed by the program. Hmm...
∂09-Mar-87 1511 Moon@STONY-BROOK.SCRC.Symbolics.COM Cleanup committee meeting at PARC, Sunday 2 PM
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Mar 87 15:11:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88750; Mon 9-Mar-87 18:11:22 EST
Date: Mon, 9 Mar 87 18:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Cleanup committee meeting at PARC, Sunday 2 PM
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870309-113616-2074@Xerox>
Message-ID: <870309181113.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I will not be on the West Coast until late Sunday night. Have a
productive meeting.
∂09-Mar-87 1941 RAM@C.CS.CMU.EDU PEEK-CHAR-READ-CHAR-ECHO
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87 19:41:09 PST
Received: ID <RAM@C.CS.CMU.EDU>; Mon 9 Mar 87 22:13:41-EST
Date: Mon, 9 Mar 1987 20:31 EST
Message-ID: <RAM.12285133039.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PEEK-CHAR-READ-CHAR-ECHO
In-reply-to: Msg of 9 Mar 1987 16:40-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Well, actually what Hemlock does is rather complicated, but different
from all the things you discussed. It does preserve proper sequencing
of input and output between packets of input, but does so by inserting
output at the end of the last read packet. This is layered on top of
an IPC protocol that normally transmits text a line at a time.
Your example will still lose, but I think that this could be
interpreted as a non-portability of the user rather than of the
program. If you obeyed the appropriate local convention of delimiting
distinct inputs with <Do-It> then it would work.
Although I think that this system works great, the point is not to
debate the relative merits of kinds of user interaction; the point is
that there's lots of ways to do it, and some of them haven't even been
thought of yet. Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal interaction
must or even ought to work.
Rob
∂09-Mar-87 1942 FAHLMAN@C.CS.CMU.EDU PEEK-CHAR-READ-CHAR-ECHO
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87 19:42:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 22:14:42-EST
Date: Mon, 9 Mar 1987 21:26 EST
Message-ID: <FAHLMAN.12285143140.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PEEK-CHAR-READ-CHAR-ECHO
In-reply-to: Msg of 9 Mar 1987 16:40-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
Kent,
I agree that for text-based dialog-type interactions, such as the one
you demonstrated, your unbuffered input model works better than
Hemlock's buffered one. However, for most kinds of interaction with
Lisp, a simple unbuffered listener cannot begin to match the convenience
of using an editor-based Lisp listener like the one we have in Hemlock.
I've been using this for a couple of years now, and can't imagine going
back to an old Maclisp-style unbuffered listener for daily use. As far
as I'm concerned, any Lisp that doesn't have a first-rate Emacs listener
is unusable. This is not just a matter of preferring what I'm familiar
with -- I was very much at home in unbuffered Maclisp and one time, and
also spent a period of involuntary exile on a line-mode Tops-10 Maclisp,
so I've had ample opportunity to experience all three styles.
I think that once such editor top-level modes are readily available,
you'll find that the overwhelming majority of users favor them. For
some reason this style of interaction hasn't taken hold on Symbolics and
TI machines; I suspect that this is because the editor top-level on Lisp
machines has always had a few critical details wrong, but I'm not sure.
And, of course, the Interlisp culture is completely different.
Anyway, I feel as strongly about the advantages of this input style as
you probably feel about the advantages of a bit-mapped screen over a
24x80 ASCII terminal. I would fight very hard against any proposal that
would take this editor-based listener away from me or that would force
the output to go to a separate editor buffer. There is the problem of
running conversational text-oriented code in an editor-based system. I
don't think we have a really clean solution to that yet, but we have the
option of dropping into an unbuffered-input listener when running such
code. Or we could use the kind of separate echo/output buffer that you
suggest for this kind of interaction. I'm happy to go as a tourist, but
I won't live there.
Even for us occasional tourists, it is worthwhile cleaning up the
semantics of echo streams and unbuffered interactive streams, so I
support your basic proposal, as long as it doesn't force every Common
Lisp to use this as the default model for interactive I/O.
-- Scott
∂09-Mar-87 2017 RPG Sunday Meeting
To: cl-cleanup@SAIL.STANFORD.EDU
I will appear at the hotel at 1:45. It is 10 minutes to
PARC from the hotel.
-rpg-
∂09-Mar-87 2025 FAHLMAN@C.CS.CMU.EDU Scott's Remarks on FUNCTION Type
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87 20:25:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 23:25:29-EST
Date: Mon, 9 Mar 1987 23:25 EST
Message-ID: <FAHLMAN.12285164736.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Scott's Remarks on FUNCTION Type
JAR pointed out that my remark about ENSURE-FUNCTION eliminating the
need for the FUNCTION speical form was confused.
I was thinking that ENSURE-FUNCTION would evaluate its argument and then
do whatever FUNCTION does on the result. But since ENSURE-FUNCTION
receives its argument at runtime, it has no access to the lexical
environment which FUNCTION needs in order to do its thing, so this whole
view is incoherent. It is frightening to think that I still don't have
the hang of lexical thinking...
ENSURE-FUNCTION could be defined as follows:
(ENSURE-FUNCTION <lambda-form>) = <closure of lambda-form IN THE
NULL LEXICAL ENVIRONMENT>
(ENSURE-FUNCTION <symbol>) = (SYMBOL-FUNCTION <symbol>)
(ENSURE-FUNCTION <function>) = <function>
Then, if we say that FUNCALL and APPLY run their functional argument
through ENSURE-FUNCTION, I think we get something equivalent to the
semantics specified currently in CLtL. But we do need to keep FUNCTION
around so that lambdas can be closed in the current lexical environment
and so that we can get the lexically apparent definition of a symbol.
-- Scott
∂09-Mar-87 2309 RPG I sent a mail to cl-object-system
∂09-Mar-87 2154 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET I sent a mail to cl-object-system
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Mar 87 21:54:16 PST
Received: from relay2.cs.net by RELAY.CS.NET id ag16715; 10 Mar 87 0:49 EST
Received: from utokyo-relay by RELAY.CS.NET id ae14531; 10 Mar 87 0:46 EST
Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA22309; Tue, 10 Mar 87 14:31:40+0900
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA19078; Tue, 10 Mar 87 14:17:28+0900
Date: Tue, 10 Mar 87 14:17:28+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8703100517.AA19078@tansei.u-tokyo.junet>
To: fahlman@C.CS.CMU.EDU, gls@THINK.COM, ida%u-tokyo.junet@RELAY.CS.NET,
mathis@ADA20.ISI.EDU, rpg%su-ai.arpa@RELAY.CS.NET
Subject: I sent a mail to cl-object-system
I have sent a E-mail to Common-lisp-object-system @ sail.stanford.edu
as RPG suggested. I hope that mail may assist the discussions on object system,
though it was rush-typed by myself and it means english syntax was not so
much polished.
The mail contains the questions and comments on CLOS.
70% of comments are from myself and 30% are from other contributors.
Thank you
Masayuki
"a37078%ccut.u-tokyo.junet%utokyo-relay.csnet"@RELAY.CS.NET/su
Cl-object-system
Prof IDA:
Your mail arrived, but I believe people are very busy now preparing
for the meeting next week and will not answer for a while.
Also, many of the comments have already been noted and corrections
proposed.
-rpg-
∂10-Mar-87 0748 KMP@STONY-BROOK.SCRC.Symbolics.COM PEEK-CHAR-READ-CHAR-ECHO
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar 87 07:48:09 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89228; Tue 10-Mar-87 10:06:24 EST
Date: Tue, 10 Mar 87 10:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PEEK-CHAR-READ-CHAR-ECHO
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12285143140.BABYL@C.CS.CMU.EDU>
Message-ID: <870310100529.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I wasn't suggesting getting rid of Hemlock's buffered input, I was
just suggesting an alternate model of how that buffered input would
be handled. ie, that you'd see your typein, elect when to send it,
and then your typein would temporarily disappear from view in order
to allow your program to re-echo it in the appropriate place in the
output text. I'm definitely not opposed to editor toplevels. I think
they're a fine idea. I just want programs tobe able to work equally
well with or without them if that is conveniently possible, and I
believe it is. Maybe if you go back and re-read my previous message
with this in mind you'll see what I was after.
∂10-Mar-87 0748 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar 87 07:48:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89098; Tue 10-Mar-87 01:57:50 EST
Date: Tue, 10 Mar 87 01:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12284918673.BABYL@C.CS.CMU.EDU>,
The message of 9 Mar 87 02:51 EST from Dick Gabriel <RPG@SAIL.STANFORD.EDU>,
<FAHLMAN.12285028625.BABYL@C.CS.CMU.EDU>
Message-ID: <870310015739.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 9 Mar 1987 00:53 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
This 150-line message of Scott's summarized the situation very well
and I have almost nothing to add. However, I am in the mood to wax
prolix anyway.
Somewhere RPG suggested that #'COND should return an object that is
called a function, but is an error to call. I'm opposed to this.
Right now in our implementation #'COND returns an object that is
not called a function and is an error to call. Either doing that
or saying that it signals an error would get my vote.
I don't like Moon's proposal that we flush FUNCTIONP.
I think all these mumble-P predicates are worthless, but I withdraw
the suggestion to flush FUNCTIONP.
What exactly do we say that the FUNCTION special form does? How about
the following: If applied to a symbol, it returns the current functional
definition, if any, else it signals an "undefined" error. (An error is
signalled if the symbol currently names a macro or special form instead
of a function.) If applied to a lambda expression, FUNCTION returns a
function corresponding to the closure of that lambda expression in the
current lexical environment. If applied to a function, it returns that
function unchanged.
I'm opposed to this last clause. It perpetuates the confusion between
"a function" and "the name of a function". The FUNCTION special form should
only accept "the name of a function", and should only return "a function".
What it returns is the function denoted by the name, which involves closing
in the current lexical environment if the name is a lambda-expression, which
is why FUNCTION is a special form.
Moon seems to think that interpreted functions and
interpreted closures would be distinct concepts.
In -some- implementations they -could- be distinct concepts, just as
compiled functions and compiled closures could be. I vacillate between
saying that all of the subtypes of FUNCTION are implementation-dependent
and shouldn't be standardized (thus COMPILED-FUNCTION should be
removed), and saying that programs might want to know this information,
so all the plausible subtypes should have standard names, even if they
aren't distinct in some implementations. The only thing I feel strongly
and consistently about is that COMPILED-FUNCTION should not be the only
standardized subtype of FUNCTION; it should either acquire some siblings
or go away.
Date: 08 Mar 87 2351 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Another alternative would be to define a functional form of FUNCTION,
called, for argument's sake, ENSURE-FUNCTION, such that
(ENSURE-FUNCTION <lambda-form>) = <closure corresponding to lambda-form>
(ENSURE-FUNCTION <symbol>) = (SYMBOL-FUNCTION <symbol>)
(ENSURE-FUNCTION <function>) = <function>
and then to define FUNCALL and APPLY to apply ENSURE-FUNCTION on its
first argument.
This is okay with me if it's renamed to (COERCE <argument> 'FUNCTION).
Note that it explicitly does not take a lexical environment as an argument,
it always uses the null environment (only an issue when the argument is
a lambda-expression.)
Date: Mon, 9 Mar 1987 10:57 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Yeah, this might be the right move. The FUNCTION special form now
becomes pretty useless, but we have to keep it for compatibility.
Not so, because FUNCTION encloses in the current lexical environment.
FUNCTION and COERCE-to-FUNCTION are actually at different reflective
levels (if I may pretend for a moment that I understood Brian Smith's
thesis).
Date: 08 Mar 87 2351 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Scott writes:
``I think that RPG's proposed new definition of the function type is
circular, or at least not very easy to understand: ....''
Making it disjoint from other types should help a lot; now when we say
that there are functions, we don't have to mumble about kludgey ways to
distinguish them from other types, they are already distinguished. Then
all that remains is to define their semantics, i.e. how they behave. We
don't want to appeal to the mathematical notion of function, but if we
enumerate the conceptual subtypes (even if they aren't explicit language
subtypes) of interpreted and compiled closures, possibly naked
interpreted and compiled functions, and generic functions, the idea
should come across.
∂10-Mar-87 0938 RPG Function Type
To: cl-cleanup@SAIL.STANFORD.EDU
Moon writes:
``Right now in our implementation #'COND returns an object that is
not called a function and is an error to call. Either doing that
or saying that it signals an error would get my vote.''
This is an alternative I thought of, but didn't mention. Namely,
Let <symbol> be a symbol that names not a function.
(function <symbol>), (symbol-function <symbol>), #'<symbol>
all signal an error.
If, on the other hand, we want #'<symbol'> to return a function
in all cases, then #'COND has to return a function.
-rpg-
∂10-Mar-87 1033 RPG SHARPSIGN-PLUS-MINUS-NUMBER
To: cl-cleanup@SAIL.STANFORD.EDU
I oppose this proposal. The reason is that unless there is a compelling
reason to do otherwise, it is best to have as few different rules and
concepts in a language as possible.
Let `#+' represent either `#+' or `#-'. Currently #+<object> can be such
that <object> is a symbol or a boolean expression. I don't see any gain in
expressive power if we extend this to include numbers, yet we've extended
the complexity of the language a little bit.
Furthermore, the examples given are not compelling at all - someday soon
some people will not know what I mean when I say I mailed this message
from a 10.
Symbolics-3600, IBM-360, MC68020A - these are proper machine names and
hence proper feature names.
Finally, an expression like #-3600 looks like an arithmetic expression
or a slip of the TIP for simply -3600.
-rpg-
∂10-Mar-87 1221 AKBARI@CS.COLUMBIA.EDU please add me
Received: from CS.COLUMBIA.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 12:20:33 PST
Date: Tue 10 Mar 87 15:19:44-EST
From: John C. Akbari <AKBARI@CS.COLUMBIA.EDU>
Subject: please add me
To: works-request@RUTGERS.RUTGERS.EDU, cl-windows@SAIL.STANFORD.EDU,
common-lisp@SAIL.STANFORD.EDU
Message-ID: <12285338462.45.AKBARI@CS.COLUMBIA.EDU>
to your list.
ad...THANKS...vance!
john c akbari
ARPANET & Internet akbari@CS.COLUMBIA.EDU
BITnet akbari%CS.COLUMBIA.EDU@WISCVM.WISC.EDU
uucp & usenet ...!seismo!columbia!cs!akbari
DECnet akbari@cs
PaperNet 380 riverside drive, no. 7d
new york, new york 10025 usa
SoundNet 212.662.2476
-------
∂10-Mar-87 1256 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 12:55:57 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 10 Mar 87 15:50:25-EST
Date: Tue, 10 Mar 1987 15:49 EST
Message-ID: <FAHLMAN.12285343870.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE
In-reply-to: Msg of 10 Mar 1987 01:57-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
If applied to a function, it (FUNCTION) returns that
function unchanged.
I'm opposed to this last clause. It perpetuates the confusion between
"a function" and "the name of a function". The FUNCTION special form should
only accept "the name of a function", and should only return "a function".
What it returns is the function denoted by the name, which involves closing
in the current lexical environment if the name is a lambda-expression, which
is why FUNCTION is a special form.
I agree that your view of this is conceptually cleaner. The main reason for
allowing functions to pass through FUNCTION unchanged was to allow us to
turn Lambda into a special form that, when executed, returns a function
closed in the current environment. The form #'(lambda ...) could be
deprecated if we do this, but it would be nice not to have to find all
the occurrences of this form and fix them. I was afraid that this
prospect might make people balk at the change to lambda. But the
process of eliminating #'(lambda ...) can be automated, so I don't feel
too strongly about this. And if we don't adopt the change to Lambda,
then Moon's version of FUNCTION is better.
Yeah, this might be the right move. The FUNCTION special form now
becomes pretty useless, but we have to keep it for compatibility.
Not so, because FUNCTION encloses in the current lexical environment.
Right, temporary insanity on my part. Guess I should try again to read
Brian Smith's thesis...
-- Scott
∂10-Mar-87 1259 edsel!babel!lnz@navajo.stanford.edu [navajo!KMP@STONY-BROOK.SCRC.Symbolics.COM: PEEK-CHAR-READ-CHAR-ECHO]
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 12:59:17 PST
Received: by navajo.stanford.edu; Tue, 10 Mar 87 12:56:37 PST
Received: from gomorrah.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01145; Tue, 10 Mar 87 12:22:12 pst
Received: by gomorrah.edsel.uucp (4.12/9.2)
id AA00381; Tue, 10 Mar 87 12:19:02 pst
Date: Tue, 10 Mar 87 12:19:02 pst
From: edsel!babel!lnz@navajo.stanford.edu (Leonard Zubkoff)
Message-Id: <8703102019.AA00381@gomorrah.edsel.uucp>
To: babel!jonl@navajo.stanford.edu
Cc: babel!jim@navajo.stanford.edu,
navajo!fahlman%c.cs.cmu.edu@navajo.stanford.edu,
navajo!kmp%stony-brook.scrc.symbolics.com@navajo.stanford.edu,
navajo!cl-cleanup%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: Jon L White's message of Tue, 10 Mar 87 08:47:51 PST <8703101647.AA02967@bhopal.edsel.com>
Subject: [navajo!KMP@STONY-BROOK.SCRC.Symbolics.COM: PEEK-CHAR-READ-CHAR-ECHO]
JonL,
KMP's description of interaction on the APOLLO sounds correct to me;
apparently, APOLLO does not share KMP's view of how input and output should be
handled. DOMAIN/CommonLISP's behavior is consistent with the general APOLLO
user interface. The Display Manager echo's input (including the prompt) from
the input pad to the transcript pad when it is read by the program; until input
is read, it may be edited or deleted at any time. Interaction with Lisp is
entirely analogous to interaction with the DOMAIN Shells, and most other
programs. Note the use of the term "transcript pad" here; it is precisely
that, a complete transcript of interaction with the program including prompts,
typein, and typeout. It is not a display window in the sense KMP suggests.
In order to implement a scheme such as KMP suggests, Lisp would be forced to
use a "raw" input mode, and would lose support for the normal features of the
APOLLO Display Manager's user interface (which I don't believe could be
entirely simulated in Lisp). While interaction style consistency across Common
Lisp implementations is a noble goal, I think cultural compatibility with the
environment in which Common Lisp runs is essential to user acceptance.
Leonard
∂10-Mar-87 1355 FAHLMAN@C.CS.CMU.EDU PEEK-CHAR-READ-CHAR-ECHO
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 13:54:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 10 Mar 87 16:18:51-EST
Date: Tue, 10 Mar 1987 16:05 EST
Message-ID: <FAHLMAN.12285346849.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PEEK-CHAR-READ-CHAR-ECHO
In-reply-to: Msg of 10 Mar 1987 10:05-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>
OK, I did misunderstand your earlier suggestion. I read it as
suggesting that the input editing would be done in one buffer, while the
echoing and interspersed output goes to another. I've tried an editor
listener that sends the output to a separate buffer from the input (on
the H-P system), and I'm pretty sure it's not the right thing.
Your suggestion, in which the input disappears and then is re-created by
echoing, is an interesting one, and worth trying. I'm not ready to
commit to it yet, however. there are lots of subtle factors that affect
the comfort of a top-level mode.
I think that Rob's position is right: there are many ways of handling
Lisp-listener interaction, some not thought of yet, and we don't want to
close any doors prematurely. I think that if we can define what "the
right thing" is for some lowest-common-denominator model like unbuffered
char-at-a-time input, then we can at least begin to play with ways of
making this shared model look right within the other more complex styles
we want to support.
-- Scott
∂10-Mar-87 1417 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar 87 14:16:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89832; Tue 10-Mar-87 17:16:01 EST
Date: Tue, 10 Mar 87 17:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12285343870.BABYL@C.CS.CMU.EDU>
Message-ID: <870310171555.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 10 Mar 1987 15:49 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
If applied to a function, it (FUNCTION) returns that
function unchanged.
I'm opposed to this last clause. It perpetuates the confusion between
"a function" and "the name of a function". The FUNCTION special form should
only accept "the name of a function", and should only return "a function".
What it returns is the function denoted by the name, which involves closing
in the current lexical environment if the name is a lambda-expression, which
is why FUNCTION is a special form.
I agree that your view of this is conceptually cleaner. The main reason for
allowing functions to pass through FUNCTION unchanged was to allow us to
turn Lambda into a special form that, when executed, returns a function
closed in the current environment. The form #'(lambda ...) could be
deprecated if we do this, but it would be nice not to have to find all
the occurrences of this form and fix them. I was afraid that this
prospect might make people balk at the change to lambda. But the
process of eliminating #'(lambda ...) can be automated, so I don't feel
too strongly about this. And if we don't adopt the change to Lambda,
then Moon's version of FUNCTION is better.
This makes no sense. The FUNCTION special form doesn't evaluate its argument,
so it makes no difference what that Lisp object would happen to do if it
were evaluated. The only way a function would need to pass unchanged through
the FUNCTION special form would be if a function appeared in source code.
Since there is no standardized printed representation for functions, this
seems unlikely. I assume we don't have to worry very much about
what #'#.(lambda ...) does; I propose that it signals an error.
Right, temporary insanity on my part. Guess I should try again to read
Brian Smith's thesis...
(-: Don't bother, the most likely result would be permanent insanity (or
sore arms from holding it up for the weeks it takes to read). :-)
Actually, there is a short version (I assume it's an MIT AI memo, I can't
quite remember) which I found fairly understandable, and I'd recommend
reading that. It's still 100 pages or so.
∂10-Mar-87 1442 RPG Consistency is the Hob....
To: cl-cleanup@SAIL.STANFORD.EDU
The following two quotes are taken from messages by the same
individual. They were mailed about a week apart. Enjoy:
``I don't believe that APPLY and FUNCALL should say that their <function>
argument must be a function.... Just say that APPLY and FUNCALL accept
either a function or a symbol....''
``I'm opposed to this last clause. It perpetuates the confusion between "a
function" and "the name of a function".''
-rpg-
∂10-Mar-87 1512 gls@Think.COM PEEK-CHAR-READ-CHAR-ECHO: nostalgia
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 10 Mar 87 15:12:29 PST
Received: from boethius by Think.COM via CHAOS; Tue, 10 Mar 87 17:39:22 EST
Date: Tue, 10 Mar 87 17:40 EST
From: Guy Steele <gls@Think.COM>
Subject: PEEK-CHAR-READ-CHAR-ECHO: nostalgia
To: Fahlman@c.cs.cmu.edu, KMP@scrc-stony-brook.arpa
Cc: CL-Cleanup@sail.stanford.edu, gls@think.com
In-Reply-To: <FAHLMAN.12285346849.BABYL@C.CS.CMU.EDU>
Message-Id: <870310174014.2.GLS@BOETHIUS.THINK.COM>
Date: Tue, 10 Mar 1987 16:05 EST
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Your suggestion, in which the input disappears and then is re-created by
echoing, is an interesting one, and worth trying. I'm not ready to
commit to it yet, however. there are lots of subtle factors that affect
the comfort of a top-level mode.
Unless I am mistaken, ITS usually worked that way.
--Guy
∂10-Mar-87 1602 yeung@cseb.usc.edu Mailing list
Received: from USC-CSE.USC.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 16:00:55 PST
Received: from cseb.usc.edu by usc-cse.usc.edu via TCP (4.12/S2.5) id AA25631; Tue, 10 Mar 87 15:18:09 pst
Received: by cseb.usc.edu (4.12/C1.12) id AA04172; Tue, 10 Mar 87 14:47:54 pst
Date: Tue, 10 Mar 87 14:47:54 pst
From: yeung@cseb.usc.edu (Dit-Yan Yeung)
Message-Id: <8703102247.AA04172@cseb.usc.edu>
To: common-lisp@su-ai.arpa
Subject: Mailing list
Could you add me to the mailing list? Thanks,
Dit-Yan
∂10-Mar-87 1626 Masinter.pa@Xerox.COM Re: Consistency is the Hob....
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Mar 87 16:26:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 MAR 87 15:28:44 PST
Date: 10 Mar 87 15:28 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Consistency is the Hob....
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 10 Mar 87
14:42 PST
To: RPG@SAIL.STANFORD.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870310-152844-1933@Xerox>
Richard,
I don't see the irony that you apparently do. There is good reason to
avoid introducing incompatibility in the operation of APPLY and FUNCALL.
We should be very cautious about how things behave. On the other hand,
we have a great deal of flexibility in crafting the way things are
*described*. If you think Moon is being inconsistent, you need to say
so more directly, and explain why.
It sounds to me that the only major question remaining in the
function-type proposal is the handling of #'cond and #'a-macro, and the
handling of (symbol-function 'cond) and (symbol-function 'a-macro).
I think no-one wants (function foo) to be different from #'foo.
The positions are:
"is an error" #'cond (symbol-function 'cond) #'a-macro
(symbol-function 'a-macro) are errors. Implementations are free to
signal errors
"signals an error" same, but implementations are required to signal
errors
"returns an unspecified value" The value returned is not specified,
but implementations may not signal an error.
"returns a function" The value returned must of type function, but
attempting to call it signals an error.
My personal belief is that "is an error" reflects current practice,
i.e., the language in CLtL is vague enough to admit all of the other
interpretations.
Would the rest of you feel comfortable with a specification which said
that (symbol-function 'cond) "is an error"?
∂10-Mar-87 1637 Moon@STONY-BROOK.SCRC.Symbolics.COM PEEK-CHAR-READ-CHAR-ECHO
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar 87 16:37:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89969; Tue 10-Mar-87 19:36:27 EST
Date: Tue, 10 Mar 87 19:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PEEK-CHAR-READ-CHAR-ECHO
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12285133039.BABYL@C.CS.CMU.EDU>
Message-ID: <870310193621.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 9 Mar 1987 20:31 EST
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
Fixing echo streams is fine, but I don't think that
it is appropriate for the standard to specify how terminal interaction
must or even ought to work.
I agree with this comment. I'm going to refrain from commenting on
the rest of the discussion.
∂10-Mar-87 1717 FAHLMAN@C.CS.CMU.EDU FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 17:17:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 10 Mar 87 20:17:41-EST
Date: Tue, 10 Mar 1987 20:17 EST
Message-ID: <FAHLMAN.12285392689.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: FUNCTION-TYPE
In-reply-to: Msg of 10 Mar 1987 17:15-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This makes no sense. The FUNCTION special form doesn't evaluate its argument,
so it makes no difference what that Lisp object would happen to do if it
were evaluated.
OK, you're right. So #'(lambda ...) should close the lambda in the
current lexical environment, as it always has. #'<some-symbol> should
get that symbol's definition in the current lexical environment, if that
symbol currently names a function, else it signals an error. And
FUNCTION of anything else signals an error.
This leaves us free to say that a lambda expression, when evaluated, is
the same as (FUNCTION (lambda...)). That is, it also returns a function
corresponding to the closure of that lambda in the current lexical
environment. So old code full of #'(lambda ...) forms would continue to
work.
Right?
-- Scott
∂10-Mar-87 1803 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Mar 87 18:02:02 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 10 Mar 87 21:02:06-EST
Date: Tue, 10 Mar 1987 21:01 EST
Message-ID: <FAHLMAN.12285400756.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: #'cond, etc.
In-reply-to: Msg of 10 Mar 1987 18:28-EST from Masinter.pa at Xerox.COM
I would be most comfortable with the following position, intermediate
between Larry's choices:
#'anything is absolutely equivalent to (FUNCTION anything) in all cases.
(FUNCTION <symbol>), where the symbol names a function in the current
lexical context, returns that function. If the symbol names a
special-whatever or a macro, or if it currently has no definition, then
a error IS SIGNALLED.
If SYMBOL-FUNCTION is called on a symbol that names a function in the
current lexical context, it returns that function. It IS AN ERROR to
call it on a symbol that names a macro or special form -- what it
returns in thsi case, if anything, is unpredictable. Similarly, it IS
AN ERROR to pass SETF of SYMBOL-FUNCTION a value that is not a function.
Some implementations may accept this, others may signal an error.
The point is that we can tighten up FUNCTION to always return a
function, while treating SYMBOL-FUNCTION as a lower-level primitive that
implementors may use in implementing special-whatevers or macros.
If we force SYMBOL-FUNCTION to return a function in all cases or signal
an error, it is not a disaster: implementors could define some primitive
%SYMBOL-FUNCTION that returns whatever is there, and the user-visible
SYMBOL-FUNCTION wraps a type-test around this. But it seems to me like
a gratuitous incompatibilty at this point. We went out of our way to
allow freedom in the use of SYMBOL-FUNCTION, and many implementations
have taken advantage of this.
-- Scott
∂10-Mar-87 1811 Moon@STONY-BROOK.SCRC.Symbolics.COM FUNCTION-TYPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar 87 18:11:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90033; Tue 10-Mar-87 21:08:56 EST
Date: Tue, 10 Mar 87 21:08 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12285392689.BABYL@C.CS.CMU.EDU>
Message-ID: <870310210851.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 10 Mar 1987 20:17 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
This makes no sense.
Right?
Right.
∂10-Mar-87 2347 RPG Consistency
To: cl-cleanup@SAIL.STANFORD.EDU
I think if we were to choose to pursue consistency in the definition
of functions we would soon find ourselves in Lisp1-land. Larry, Scott,
and, of course, Moon are right: current Common Lisp programming practice
confuses functions and symbols (names for functions). There is a limit
on how far down the consistency path we can go before we fundamentally
change Common Lisp to Lisp1.
MacLisp-trained Common-Lispers are not used to thinking about symbols and
functions in a deep way, and even people who return to first principles in
the form of Lisp 1.5 also see a confusion in this area. Notice that
Scott, who is quite Lisp-knowledgeable, in his last message talked about
``symbols that name functions in the current lexical context,'' but
symbols are in a global context. This signals to me that thinking in
precise and consistent terms about functions and symbols is not part of
current Common Lisp practice. So there is no point in pursuing consistency
very far, and we compromise.
Scott's compromise on FUNCTION and SYMBOL-FUNCTION is probably as
good as we can do.
-rpg-
∂11-Mar-87 0928 FAHLMAN@C.CS.CMU.EDU #'anything
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Mar 87 09:27:57 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Mar 87 12:26:24-EST
Date: Wed, 11 Mar 1987 12:26 EST
Message-ID: <FAHLMAN.12285569035.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: edsel!bhopal!jonl@λnavajo.stanford.edu (Jon L White)λ
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: #'anything
In-reply-to: Msg of 11 Mar 1987 10:45-EST from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Date: Wednesday, 11 March 1987 10:45-EST
From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
To: navajo!Fahlman%C.CS.CMU.EDU at navajo.stanford.edu
cc: Masinter.pa at xerox.com, cl-cleanup at sail.stanford.edu
Re: #'anything
Re: #'anything is absolutely equivalent to (FUNCTION anything) in all cases.
(FUNCTION <symbol>), where the symbol names a function in the current
lexical context, returns that function. . . .
As I remember it, the intent was that (FUNCTION <symbol>) would refer
to the innermost lexical function binding (as by flet, labels) if any,
or to the global function binding otherwise; (SYMBOL-FUNCTION '<symbol>)
would always refer to the global binding. Are you really proposing to
do away with this distinction?
No. What ever gave you that idea? When I say that "symbol names a
function in the current lexical context" I mean exactly what you just
said that FUNCTION does, and I'm not proposing to change SYMBOL-FUNCTION
at all, except to clarify what is and is not an error.
I guess my choice of words in describing FUNCTION was a poor choice,
since it has bothered both you and RPG, though I still don't see the
problem. In any event, we should use something like your wording
instead.
-- Scott
∂11-Mar-87 0930 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 09:30:05 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90502; Wed 11-Mar-87 12:23:54 EST
Date: Wed, 11 Mar 87 12:23 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (revision 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870226224504.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870311122304.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: IGNORE-ERRORS
References: p428
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/26/87,
Revision 2 by KMP 02/26/87 (fixed typo in sample code),
Revision 3 by KMP 03/11/87 (change to 2nd return value)
Problem Description:
Common Lisp has no way to trap an error inhibiting entry to the debugger.
Proposal (IGNORE-ERRORS:INTERIM):
Remove the apology for the absence of ERRSET on p428 and introduce
mention of a new macro called IGNORE-ERRORS with the syntax
(IGNORE-ERRORS {form}*)
Say that it attempts to execute the given forms in order from left to right,
returning all the values returned by the last form (or NIL if there
are no forms).
Say also that if an error occurs while executing the forms, no error
message is printed; instead control is silently transfered to the
IGNORE-ERRORS form, which immediately returns a principal value of NIL.
The return value convention for any other values besides the principal
return value in the case of an error is expressly left undefined in order
to leave room for the full error proposal to attach a useful meaning
which cannot be described in the absence of that proposal.
Rationale:
It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next CL spec.
The baroque return value convention used by Maclisp's ERRSET special form
(mentioned on p428 of CLtL) does not extend gracefully to situations multiple
values.
Current Practice:
Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.
Adoption Cost:
As far as I know, this would not be difficult to implement in any implementation.
eg, IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS)
(LET ((TAG (GENSYM)))
`(BLOCK ,TAG
(ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
NIL)))
Benefits:
An error proposal is in the works which will offer IGNORE-ERRORS and more.
In case of delays or problems in the acceptance of the spec, applications
developers will not have to worry that they'll end up with no way to trap
errors.
Conversion Cost:
User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.
Aesthetics:
This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
∂11-Mar-87 0931 RPG Consistency
∂11-Mar-87 0829 FAHLMAN@C.CS.CMU.EDU Consistency
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Mar 87 08:29:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Mar 87 11:29:53-EST
Date: Wed, 11 Mar 1987 11:29 EST
Message-ID: <FAHLMAN.12285558743.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Subject: Consistency
In-reply-to: Msg of 11 Mar 1987 02:47-EST from Dick Gabriel <RPG at SAIL.STANFORD.EDU>
No point in arguing about this before the whole committee, but I don't
believe that consistency in handling functions and function names must
inevitably lead one to Lisp1. Common Lisp is a Lisp2, and is grossly
inconsistent in places; Scheme is a Lisp1, and is more internally
consistent. But I think that this difference has more to do with the
processes that gave rise to the two languages than to any inherent
inconsistency in a Lisp2 approach.
MacLisp-trained Common-Lispers are not used to thinking about symbols and
functions in a deep way, and even people who return to first principles in
the form of Lisp 1.5 also see a confusion in this area. Notice that
Scott, who is quite Lisp-knowledgeable, in his last message talked about
``symbols that name functions in the current lexical context,'' but
symbols are in a global context.
I don't understand this last comment. I'm not being defensive, but I
really don't see anything wrong with what I said, so maybe there's
something deep that I really don't understand. We're talking here about
a call like (FUNCTION <symbol>), which does look up the symbol's
associated funciton in the current lexical environment, does it not? Of
course the symbols exist in a global context; the phrase "in the current
lexical context" was meant to modify "name".
Of course, your point is still made by the fact that I lost track of the
fact that a normal function could not look up the definition of its
argument in the current lexical context. So (some) people from the
Maclisp/Common Lisp tradition do not always have a firm grip on this
lexical business -- either for functions or for variables. I still get
frequent requests to fix the "bug" that EVAL used the null lexical
context instead of the current one.
Also, I think it is very strange to think of Lisp 1.5 as in any way
representing first principles. As Lisp 1.5 evolved into Maclisp and
other dialects, a few things got uglier in the name of efficiency, but
many godawful crocks got cleaned up. Lisp 1.5 is already a very long
way from the Lambda calculus.
-- Scott
Fahlman@c.cs.cmu/su
Consistency
Scott, I don't think we're disagreeing in any fundamental way about what
should happen with CL, only about how far consistency takes us. I think
that if we take consistency as the number 1 goal and add a dash of aesthetics,
we get Lisp1. The dash is something I left out of my message.
The notation (FUNCTION <symbol>) means that the form on which FUNCTION
operates is a reference to a symbol.
(FUNCTION <variable>) means the form is a variable reference (FUNCTION
<identifier>) means the form is either a variable reference or a symbol
reference.
I think if you take (FUNCTION <symbol>) to mean (FUNCTION <identifier>),
your statement is right. But this simply goes along with my statement that
a perfectly first-class hacker with no need to think about underlying
semantics in a deep way (in an obsessive way) doesn't need to worry about
some surface inconsistencies. In MacLisp and other dynamic-variable Lisps,
there is not a strong a need to distinguish symbols from variables, while
in a lexical Lisp there is such a need.
In terms of first principles, I didn't qualify my statement enough. I could
have said more precisely ``first-principles-in-the-form-of-Lisp-1.5,'' or
first principles as thought of as encompassed by Lisp 1.5. That is,
Lisp 1.5 comprises the first principles to some class of person.
-rpg-
∂11-Mar-87 0938 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 09:38:18 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90502; Wed 11-Mar-87 12:23:54 EST
Date: Wed, 11 Mar 87 12:23 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (revision 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870226224504.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870311122304.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: IGNORE-ERRORS
References: p428
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/26/87,
Revision 2 by KMP 02/26/87 (fixed typo in sample code),
Revision 3 by KMP 03/11/87 (change to 2nd return value)
Problem Description:
Common Lisp has no way to trap an error inhibiting entry to the debugger.
Proposal (IGNORE-ERRORS:INTERIM):
Remove the apology for the absence of ERRSET on p428 and introduce
mention of a new macro called IGNORE-ERRORS with the syntax
(IGNORE-ERRORS {form}*)
Say that it attempts to execute the given forms in order from left to right,
returning all the values returned by the last form (or NIL if there
are no forms).
Say also that if an error occurs while executing the forms, no error
message is printed; instead control is silently transfered to the
IGNORE-ERRORS form, which immediately returns a principal value of NIL.
The return value convention for any other values besides the principal
return value in the case of an error is expressly left undefined in order
to leave room for the full error proposal to attach a useful meaning
which cannot be described in the absence of that proposal.
Rationale:
It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next CL spec.
The baroque return value convention used by Maclisp's ERRSET special form
(mentioned on p428 of CLtL) does not extend gracefully to situations multiple
values.
Current Practice:
Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.
Adoption Cost:
As far as I know, this would not be difficult to implement in any implementation.
eg, IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS)
(LET ((TAG (GENSYM)))
`(BLOCK ,TAG
(ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
NIL)))
Benefits:
An error proposal is in the works which will offer IGNORE-ERRORS and more.
In case of delays or problems in the acceptance of the spec, applications
developers will not have to worry that they'll end up with no way to trap
errors.
Conversion Cost:
User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.
Aesthetics:
This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
∂11-Mar-87 1004 KMP@STONY-BROOK.SCRC.Symbolics.COM IGNORE-ERRORS (revision 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 10:04:19 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90502; Wed 11-Mar-87 12:23:54 EST
Date: Wed, 11 Mar 87 12:23 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (revision 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870226224504.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870311122304.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: IGNORE-ERRORS
References: p428
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 02/26/87,
Revision 2 by KMP 02/26/87 (fixed typo in sample code),
Revision 3 by KMP 03/11/87 (change to 2nd return value)
Problem Description:
Common Lisp has no way to trap an error inhibiting entry to the debugger.
Proposal (IGNORE-ERRORS:INTERIM):
Remove the apology for the absence of ERRSET on p428 and introduce
mention of a new macro called IGNORE-ERRORS with the syntax
(IGNORE-ERRORS {form}*)
Say that it attempts to execute the given forms in order from left to right,
returning all the values returned by the last form (or NIL if there
are no forms).
Say also that if an error occurs while executing the forms, no error
message is printed; instead control is silently transfered to the
IGNORE-ERRORS form, which immediately returns a principal value of NIL.
The return value convention for any other values besides the principal
return value in the case of an error is expressly left undefined in order
to leave room for the full error proposal to attach a useful meaning
which cannot be described in the absence of that proposal.
Rationale:
It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next CL spec.
The baroque return value convention used by Maclisp's ERRSET special form
(mentioned on p428 of CLtL) does not extend gracefully to situations multiple
values.
Current Practice:
Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.
Adoption Cost:
As far as I know, this would not be difficult to implement in any implementation.
eg, IGNORE-ERRORS is trivially implemented in terms of ERRSET...
(DEFMACRO IGNORE-ERRORS (&BODY FORMS)
(LET ((TAG (GENSYM)))
`(BLOCK ,TAG
(ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
NIL)))
Benefits:
An error proposal is in the works which will offer IGNORE-ERRORS and more.
In case of delays or problems in the acceptance of the spec, applications
developers will not have to worry that they'll end up with no way to trap
errors.
Conversion Cost:
User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.
Aesthetics:
This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.
Discussion:
KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
∂11-Mar-87 1052 KMP@STONY-BROOK.SCRC.Symbolics.COM PROMPT-FOR
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 10:52:20 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90602; Wed 11-Mar-87 13:50:50 EST
Date: Wed, 11 Mar 87 13:50 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROMPT-FOR
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Pavel.PA@Xerox.COM
Message-ID: <870311135002.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: PROMPT-FOR
References: None
Category: ENHANCEMENT
Edit history: Revision 1 by KMP 03/11/87
Problem Description:
Common Lisp has no reader function which reads an object
of a given type. Such a thing can more or less be written
in user code, but it's done often enough to warrant
consideration for entry into the system.
Proposal (PROMPT-FOR:OK)
Introduce a new function PROMPT-FOR with the following syntax:
(PROMPT-FOR typespec &optional format-string &rest format-arguments)
This function would prompt for an object for which
(TYPEP object 'typespec) was true. Prompting would begin on
a fresh line. The FORMAT-STRING and FORMAT-ARGUMENTS would
be used to do prompting; if not supplied, the default prompt
would be something like "Enter an expression of type <typespec>: ".
The expression would be parsed by READ and checked to assure that
it was of the appropriate type. If it was not of the appropriate
type, the system would indicate the problem and ask the user for
a correction. The entire interaction would take place on the
stream in *QUERY-IO*.
Rationale:
1. This is a common idiom that many programs would have use for.
It would be useful to standardize on a common interface.
The need will be all the more compelling if and when the
new error system is approved.
2. Currently, this function could be written a user program:
(DEFUN PROMPT-FOR (TYPESPEC &OPTIONAL FORMAT-STRING
&REST FORMAT-ARGUMENTS)
(FLET ((GET-INPUT ()
(FRESH-LINE *QUERY-IO*)
(COND ((NOT FORMAT-STRING)
(FORMAT *QUERY-IO*
"Enter an expression of type ~S: "
TYPESPEC))
(T
(APPLY #'FORMAT *QUERY-IO* FORMAT-STRING
FORMAT-ARGUMENTS)))
(READ *QUERY-IO*)))
(DO ((FORM (GET-INPUT) (GET-INPUT)))
((TYPEP FORM TYPESPEC) FORM)
(FORMAT *QUERY-IO* "~&The object ~S is not acceptable.~%"
FORM))))
However, such an implementation is at a severe disadvantage
because:
a. The prompt and the call to READ are not closely coupled.
If the user clears the screen in the middle of the READ
-- an operation allowed by many rubout processors, there
is no way to know that a prompt should have been
redisplayed. By coupling prompting and reading into a
single component supplied by the system, prompting can
be accomplished using primitives that are beyond the
scope of the current spec.
b. On Lisp Machines, for example, this type check could be
accomplished from within the rubout handler, allowing the
user to rub back into the expression to correct it rather
than requiring that he be reprompted. In other
implementations, such might not be possible, but it still
might be desirable to stuff the input buffer with the
offending expression on subsequent calls to READ so that
it could be easily edited. That cannot currently be done
from user code.
Current Practice:
There is no current practice. This would extend Common Lisp in
a new direction. Several implementations probably already provide
private extensions of a similar kind.
Adoption Cost:
Negligible. The code above would be adequate to satisfy the
proposed definition. Any additional work would be to integrate it
better into a particular environment and is not rightly a cost
attributable to the change.
Benefits:
A common idiom would have a standardized calling interface.
Some programs would have more useful prompting and error
recovery behaviors.
The emerging Error System compounds the need for this because
many kinds of error recovery strategies involve prompting for
corrected data and verifying that the values read are of some
particular type. As such, this primitive will probably eventually
be in your Common Lisp either privately as an internal part of
the error system or publicly. Since it is useful for a wider
variety of things, it would seem worth making it standard.
Conversion Cost:
No user code would have to be modified (other than code which
assumed that the new name was available for private use --
something which is trivially detectable and fixable in most
editing environments).
Aesthetics:
There are those who believe that any new feature adds complexity.
I think, however, that if such new features offer significant new
expressional power, as this one does, the complexity is paid for
many times over.
Discussion:
KMP made this proposal, so he supports it.
In notes made by Pavel Curtis on the emerging error system, he
complained that the READ-TYPED-OBJECT primitive used in many of
the examples was not defined in the proposal. He didn't complain
similarly for other more whimsical things not defined. KMP took
this as implicit support for the idea that some sort of facility
like this might be welcomed by the Xerox crowd.
Symbolics has recently introduced an extension called ACCEPT
which does something similar, but uses stylized readers on a
per-type basis. It should be clear that this proposal intends
to propose that READ be used in all cases. The Symbolics ACCEPT
primitive is very useful but requires more baggage than I think
CL would be willing to accept at this time.
∂11-Mar-87 1341 Moon@YUKON.SCRC.Symbolics.COM PROMPT-FOR
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 13:41:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 177254; Wed 11-Mar-87 15:59:56 EST
Date: Wed, 11 Mar 87 15:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROMPT-FOR
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870311135002.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870311155942.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 11 Mar 87 13:50 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Issue: PROMPT-FOR
....
Symbolics has recently introduced an extension called ACCEPT
which does something similar, but uses stylized readers on a
per-type basis. It should be clear that this proposal intends
to propose that READ be used in all cases.
I disagree with that part of your proposal. I don't think it's
appropriate to standardize on something that requires the user input in
response to the prompt to be entered in an inferior syntax. Suppose,
for example, that you are asking the user to enter a pathname. I think
the user expects to type just the pathname in its host-specific syntax,
not #P"pathname" (in Symbolics systems), or #⊂pathname⊃ (in LMI systems),
or #S(pathname ...), etc. Since the type of object being entered is
known, the syntax that allows READ to distinguish it from other types
of objects is unnecessary baggage. I don't see why the syntax of the
user input should be standardized at all, just as Common Lisp doesn't
standardize on whether the user input comes from a keyboard, a mouse,
voice recognition, or a ouija board.
Instead, I think you should propose to standardize the program interface,
through which the program specifies what type of input it wants and
how it will prompt for it, but say that how this interacts with the
user is up to individual system environments.
Since there is some possibility of a subset of Symbolics' ACCEPT
being proposed as a standard, you might want to make your proposal be
more compatible with it. That would mostly involve accepting keyword
arguments, for expandability, and changing the way the prompt is
specified. Otherwise we could end up with two incompatible standards
for no good reason.
∂11-Mar-87 1403 Moon@STONY-BROOK.SCRC.Symbolics.COM #'cond, etc.
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 14:03:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 90892; Wed 11-Mar-87 17:02:33 EST
Date: Wed, 11 Mar 87 17:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: #'cond, etc.
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12285400756.BABYL@C.CS.CMU.EDU>
Message-ID: <870311170226.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 10 Mar 1987 21:01 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I would be most comfortable with the following position, intermediate
between Larry's choices:
#'anything is absolutely equivalent to (FUNCTION anything) in all cases.
(FUNCTION <symbol>), where the symbol names a function in the current
lexical context, returns that function. If the symbol names a
special-whatever or a macro, or if it currently has no definition, then
a error IS SIGNALLED.
If SYMBOL-FUNCTION is called on a symbol that names a function in the
current lexical context, it returns that function.
This is a typo, right? "in the current lexical context" should be "globally".
It IS AN ERROR to
call it on a symbol that names a macro or special form -- what it
returns in thsi case, if anything, is unpredictable. Similarly, it IS
AN ERROR to pass SETF of SYMBOL-FUNCTION a value that is not a function.
Some implementations may accept this, others may signal an error.
The point is that we can tighten up FUNCTION to always return a
function, while treating SYMBOL-FUNCTION as a lower-level primitive that
implementors may use in implementing special-whatevers or macros.
Except for the typo noted above, I agree with this.
If we force SYMBOL-FUNCTION to return a function in all cases or signal
an error, it is not a disaster: implementors could define some primitive
%SYMBOL-FUNCTION that returns whatever is there, and the user-visible
SYMBOL-FUNCTION wraps a type-test around this. But it seems to me like
a gratuitous incompatibilty at this point. We went out of our way to
allow freedom in the use of SYMBOL-FUNCTION, and many implementations
have taken advantage of this.
The Common Lisp Object System is going to propose a "gratuitous" incompatibility
in SYMBOL-FUNCTION anyway, I believe, although somehow it seems to have been
dropped from (or never got into) the documents that were distributed as 87-002.
It's an incompatibility for implementors, not for users, and requires there
to be underlying subprimitives that get and set the "real" function definition
of a symbol. So I guess doing the same thing here must be okay.
∂11-Mar-87 1946 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Mar 87 19:46:23 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Mar 87 22:47:05-EST
Date: Wed, 11 Mar 1987 22:47 EST
Message-ID: <FAHLMAN.12285682035.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: #'cond, etc.
In-reply-to: Msg of 11 Mar 1987 17:02-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
If SYMBOL-FUNCTION is called on a symbol that names a function in the
current lexical context, it returns that function.
This is a typo, right? "in the current lexical context" should be
"globally".
Right. It's not exactly a typo, but it is certainly not what I meant to
say. "Globally" is right. Now I see what was confusing JONL.
A "gratuitous" incompatibility ceases to be gratuitous if done for a
good reason. If the CLOS proposal wants to change SYMBOL-FUNCTION,
presumably there's some good reason.
-- Scott
∂11-Mar-87 2010 FAHLMAN@C.CS.CMU.EDU PROMPT-FOR
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Mar 87 20:10:27 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 11 Mar 87 23:11:09-EST
Date: Wed, 11 Mar 1987 23:11 EST
Message-ID: <FAHLMAN.12285686411.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: PROMPT-FOR
In-reply-to: Msg of 11 Mar 1987 15:59-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
I agree with Moon that what we should standardize on is a programmer's
interface to a query-the-user function. The style of interaction with
the user should be left up to the implementation. For example, in
Hemlock this is currently done by prompting and accepting input in the
echo area. In other systems it might be a pop-up query window. If the
item being prompted for is part of a finite set (e.g. files or legal
continuations), some systems might offer to show the user his options.
And so on.
I agree with the goal of the proposal, but would have to oppose it in
its present restrictive form.
-- Scott
∂11-Mar-87 2326 KMP@STONY-BROOK.SCRC.Symbolics.COM PROMPT-FOR
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Mar 87 23:26:00 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 91176; Wed 11-Mar-87 20:45:37 EST
Date: Wed, 11 Mar 87 20:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROMPT-FOR
To: Pavel.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870311-160709-1493@Xerox>
Message-ID: <870311204444.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Thanks for your comments. The format of your reply was fine and I'm sure
no one thinks you were butting in; I cc'd you exactly so you'd get a
chance to reply if I'd misrepresented you and/or you didn't like the
particulars of this proposal.
Moon had some useful (critical) comments about this, too.
I'd expected some people not to agree with the first cut at this, and
am not adamant about ramming this one down anyone's throat if they're
not strongly behind it. My guess is, though, that something in this
area would be worthwhile -- I think it's just a matter of finding the
right interface.
I doubt I'll find the time to pursue it further before the weekend, so
maybe we can talk about it at the Palo Alto meeting (and/or at the Mike
Jacobs PACE dance on Saturday).
-kmp
∂12-Mar-87 0924 Pavel.pa@Xerox.COM Re: PROMPT-FOR
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Mar 87 09:24:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 MAR 87 16:07:09 PST
Date: 11 Mar 87 16:06 PST
From: Pavel.pa@Xerox.COM
Subject: Re: PROMPT-FOR
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Wed, 11 Mar 87 13:50 EST
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, Pavel.PA@Xerox.COM
Message-ID: <870311-160709-1493@Xerox>
Excuse me if I use the wrong format for this message; I'm not familiar
with any structures that you folks may have set up for comments.
KMP said in a recent note:
In notes made by Pavel Curtis on the emerging error system, he
complained that the READ-TYPED-OBJECT primitive used in many of
the examples was not defined in the proposal. He didn't complain
similarly for other more whimsical things not defined. KMP took
this as implicit support for the idea that some sort of facility
like this might be welcomed by the Xerox crowd.
While I did, indeed, complain that READ-TYPED-OBJECT was undefined in
the proposal, I certainly never intended to give any support, implicit
or otherwise, to the inclusion of such a facility in Common Lisp. In
fact, wandering the halls here, the general opinion is that it doesn't
sound like a particularly appropriate facility for the standard. The
arguments given by KMP in his proposal don't sound very convincing to my
ears, at least. For example, he states,
I think, however, that if such new features offer significant new
expressional power, as this one does, the complexity is paid for
many times over.
I certainly wouldn't agree that PROMPT-FOR represents ``significant new
expressional power'', especially given the ease with which the portable
imlementation can be written.
I don't mean to butt in on your discussion, but I felt that I should
clear up an apparent misconception about my opinion on the issue.
Pavel
∂12-Mar-87 1252 JAR@AI.AI.MIT.EDU #'cond, etc.
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Mar 87 12:52:35 PST
Date: Thu, 12 Mar 87 15:55:14 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: #'cond, etc.
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU, Masinter.pa@XEROX.COM
In-reply-to: Msg of Tue 10 Mar 1987 21:01 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <167474.870312.JAR@AI.AI.MIT.EDU>
Date: Tue, 10 Mar 1987 21:01 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
(FUNCTION <symbol>), where the symbol names a function in the current
lexical context, returns that function. If the symbol names a
special-whatever or a macro, or if it currently has no definition, then
a error IS SIGNALLED.
This is asymmetric with variable reference unless the semantics of
variable references is also changed to signal an error if the variable
is unbound. Changing one and not the other would be bizarre and (to me)
distasteful, and changing either is incompatible with Common Lisp's
philosphy of permitting compiled code which in the interest of speed
omits checks like this.
Jonathan
∂12-Mar-87 1405 Moon@STONY-BROOK.SCRC.Symbolics.COM #'cond, etc.
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 Mar 87 14:02:42 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 92016; Thu 12-Mar-87 17:02:08 EST
Date: Thu, 12 Mar 87 17:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: #'cond, etc.
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, Masinter.pa@XEROX.COM
In-Reply-To: <167474.870312.JAR@AI.AI.MIT.EDU>
Message-ID: <870312170213.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 12 Mar 87 15:55:14 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Date: Tue, 10 Mar 1987 21:01 EST
From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
(FUNCTION <symbol>), where the symbol names a function in the current
lexical context, returns that function. If the symbol names a
special-whatever or a macro, or if it currently has no definition, then
a error IS SIGNALLED.
This is asymmetric with variable reference unless the semantics of
variable references is also changed to signal an error if the variable
is unbound. Changing one and not the other would be bizarre and (to me)
distasteful, and changing either is incompatible with Common Lisp's
philosphy of permitting compiled code which in the interest of speed
omits checks like this.
Good point. It's always hard for me to remember which things are
"signals an error" in Symbolics Common Lisp but "is an error" in
straight Common Lisp. I agree that the error checking in FUNCTION
is more properly "is an error", by Common Lisp's current philosophy.
∂12-Mar-87 2010 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Mar 87 20:10:09 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 12 Mar 87 23:10:41-EST
Date: Thu, 12 Mar 1987 23:10 EST
Message-ID: <FAHLMAN.12285948474.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: #'cond, etc.
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
(FUNCTION <symbol>), where the symbol names a function in the current
lexical context, returns that function. If the symbol names a
special-whatever or a macro, or if it currently has no definition, then
a error IS SIGNALLED.
This is asymmetric with variable reference unless the semantics of
variable references is also changed to signal an error if the variable
is unbound.
Well, the manual says nothing about what happens when FUNCTION is called
on a symbol that is currently unbound. There's a pointer to
SYMBOL-FUNCTION, which clearly says "signals" (page 90). A reference to
an unbound variable "is an error", while "an error occurs" for
SYMBOL-VALUE. I don't care what we do about this, but it might be worth
changing a few things to get a consistent set of rules here.
Whatever the standard says, I think that any decent implemenation will
signal an error in these cases unless the code in question is in a
function compiled with SPEED > SAFETY, but my attempt to get this into
the standard last summer stirred up so much trouble that I'm not going
to raise that issue again.
-- Scott
∂13-Mar-87 1451 JAR@AI.AI.MIT.EDU #'cond, etc.
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 13 Mar 87 14:51:39 PST
Date: Fri, 13 Mar 87 17:55:05 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: #'cond, etc.
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Thu 12 Mar 1987 23:10 EST from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <168036.870313.JAR@AI.AI.MIT.EDU>
I agree that SYMBOL-FUNCTION and SYMBOL-VALUE ought to work more or less
symmetrically. However, I see no reason for these *functions* to be
consistent (with respect to the "signals" vs. "is" question) with the
*primitive expression types* variable reference and function reference.
These two pairs of features operate at very different levels.
So how about this:
SYMBOL-VALUE, SYMBOL-FUNCTION --
These signal an error if the variable or function is unbound.
(If a symbol names a macro or special form that counts as being
"unbound" w.r.t. the function binding.)
variable reference, #'<name> --
It is an error to evaluate these if the variable or function
is unbound.
There's a world of difference between "is an error" and "signals an
error". I don't know why you mention random compiler switches in this
context, because compiler switches mustn't affect the semantics of
programs, but should only affect the way the system treats incorrect
programs. "Signals an error" doesn't imply incorrect! Quite the
opposite; when something signals an error, it isn't in error, because
the result is perfectly well defined: a condition is raised, and some
piece of user code may elect to exploit this constraint.
The phrase "to signal an error," which sounds a lot like "to be an
error," is so misleading as to warrant replacement by a more appropriate
phrase. We'll be in much better shape if we can rely on an error
proposal, since then we can always say "signals the FOO condition" for
some FOO, and need never use the term "error" for this kind of thing.
But maybe for now we could start saying "a condition is signalled" or "a
serious condition is signalled".
Jonathan
∂13-Mar-87 1724 Masinter.pa@Xerox.COM Issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Mar 87 17:24:03 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 MAR 87 17:09:06 PST
Date: 13 Mar 87 17:09 PST
From: Masinter.pa@Xerox.COM
Subject: Issues
To: cl-cleanup@sail.stanford.edu
Message-ID: <870313-170906-1285@Xerox>
Here's the list of issues that have been discussed in the mail. I have
sorted the proposals by my estimate of the likelihood of reaching
agreement convergence quickly, based on the mail traffic. I think it
would be appropriate for us to handle them in this order.
I will be in the downstairs PARC lobby at 2 PM to sign you in. If anyone
has problems or wants directions, you can call me at home at (415)
968-3794. We'll most likely meet in the colab, at (415) 494-4893.
COMPILER-WARNING-BREAK
COMPILER-WARNING-STREAM
DEFVAR-INITIALIZATION
FORMAT-ATSIGN-COLON
FLET-IMPLICIT-BLOCK
IMPORT-SETF-SYMBOL-PACKAGE (formerly IMPORT-UNCLEAR)
PRINC-CHARACTER:WRITE-CHAR
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
FORMAT-OP-C
FUNCTION-TYPE
SHARPSIGN-BACKSLASH-BITS
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
SHARPSIGN-PLUS-MINUS-NUMBER/PACKAGE
IGNORE-ERRORS
IF-BODY
PEEK-CHAR-READ-CHAR-ECHO
PROMPT-FOR
ROB'S-COMPILER-PROPOSAL (provisional title)
ENVIRONMENT-ARGUMENTS (provisional title)
(this includes macro-function-environment,
get-setf-method-environment)
∂13-Mar-87 1728 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Mar 87 17:28:07 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Mar 87 20:28:24-EST
Date: Fri, 13 Mar 1987 20:28 EST
Message-ID: <FAHLMAN.12286181070.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: #'cond, etc.
In-reply-to: Msg of 13 Mar 1987 17:55-EST from Jonathan A Rees <JAR at AI.AI.MIT.EDU>
So how about this:
SYMBOL-VALUE, SYMBOL-FUNCTION --
These signal an error if the variable or function is unbound.
(If a symbol names a macro or special form that counts as being
"unbound" w.r.t. the function binding.)
variable reference, #'<name> --
It is an error to evaluate these if the variable or function
is unbound.
OK, whatever. If some implementation fails to signal these latter two
errors when I've asked the compiler for safety, I'll complain to
Consumer Reports and not to the Common Lisp Validation Squad.
There's a world of difference between "is an error" and "signals an
error". I don't know why you mention random compiler switches in this
context, because compiler switches mustn't affect the semantics of
programs, but should only affect the way the system treats incorrect
programs. "Signals an error" doesn't imply incorrect! Quite the
opposite; when something signals an error, it isn't in error, because
the result is perfectly well defined: a condition is raised, and some
piece of user code may elect to exploit this constraint.
I disagree with this. Compiler switches mustn't affect the semantics of
correct programs, and "correct" in this context means (or should mean)
that the program neither does anything that "is an error" nor "signals
an error". "Signals" an error means "is an error" AND "signals some
condition". That's why they are called errors. If you take the word
"error" to mean "a perfectly legitimate way to invoke your favorite
handler", we will just have to make up some other word ("flaming bloody
disaster"?) for things that you can't legitimately put in portable code,
but that are guaranteed not to slip by undetected if you do.
I may not be able to get people to agree that certain errors should be
signalled if I ask for safety, though they may not be caught if I ask
for speed. But I don't think we ought to adopt terminology that would
make it impossible even to propose this.
-- Scott
∂13-Mar-87 1824 Masinter.pa@Xerox.COM Re: #'cond, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Mar 87 18:24:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 MAR 87 18:04:18 PST
Date: 13 Mar 87 17:47 PST
From: Masinter.pa@Xerox.COM
Subject: Re: #'cond, etc.
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
13 Mar 87 20:28 EST
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870313-180418-1011@Xerox>
Scott, can you give an example of something you think fits the category
of "things that you can't legitimately put in portable code, but that
are guaranteed not to slip by undetected if you do."?
∂13-Mar-87 1938 FAHLMAN@C.CS.CMU.EDU #'cond, etc.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 13 Mar 87 19:38:31 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 13 Mar 87 22:39:12-EST
Date: Fri, 13 Mar 1987 22:39 EST
Message-ID: <FAHLMAN.12286204887.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: #'cond, etc.
In-reply-to: Msg of 13 Mar 1987 20:47-EST from Masinter.pa at Xerox.COM
Scott, can you give an example of something you think fits the category
of "things that you can't legitimately put in portable code, but that
are guaranteed not to slip by undetected if you do."?
I claim that anything that lands you in the debugger when given correct
arguments (according to the program's spec) is not a correct portable
Common Lisp program, even if it lands you in the debugger in the same
way across all legal Common Lisp implementations. So if a program is
given legal inputs (according to its spec) and then calls SYMBOL-VALUE
of an unbound symbol, I would claim that this program is not "correct".
Assuming something like the KMP error system, I would go along with
using the term "correct" for a program that does something guaranteed to
signal an error, *IF* that program also provides a handler for the error
in question, so that you don't end up in the debugger. If a program
does something that "is an error", it can never be correct in this sense
-- what happens is completely unpredictable from one implemenation to
another. Of course, there are currently very few situations that
"signal an error", because for many errors it was felt that, under some
circumstances, the user would prefer maximum speed on stock hardware to
guaranteed signalling.
However, if we adopt this definition of "correct", I think we should
drop the assertion that optimize declarations cannot affect program
correctness.
What I was arguing for last summer was that we allow safety declarations
to turn certain "is an error" cases into "signals an error" cases. This
would make it possible to turn some programs that can never be correct
under the current rules into programs that are correct if you provide
the right OPTIMIZE declarations and if you handle the resulting errors
within the program. Of course, the reverse is also true: adding an
(OPTIMIZE (SPEED 3)) declaration can turn an otherwise correct program
into one that is incorrect because the error isn't signalled in some
implementations.
If we reject that view on the grounds that optimize declarations should
never affect program correctness (even in a positive way), then all
these cases must remain "is an error". This solves the problem by
making sure that none of these programs can ever be considered correct.
That doesn't seem terribly useful to me.
-- Scott
∂13-Mar-87 2121 KMP@STONY-BROOK.SCRC.Symbolics.COM #'cond, etc.
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 Mar 87 21:21:35 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 93275; Sat 14-Mar-87 00:20:47 EST
Date: Sat, 14 Mar 87 00:20 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: #'cond, etc.
To: Fahlman@C.CS.CMU.EDU
cc: JAR@AI.AI.MIT.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12286181070.BABYL@C.CS.CMU.EDU>
Message-ID: <870314002037.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Fri, 13 Mar 1987 20:28 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
... I disagree with this. Compiler switches mustn't affect the semantics of
correct programs, and "correct" in this context means (or should mean)
that the program neither does anything that "is an error" nor "signals
an error". "Signals" an error means "is an error" AND "signals some
condition". That's why they are called errors. If you take the word
"error" to mean "a perfectly legitimate way to invoke your favorite
handler", we will just have to make up some other word ("flaming bloody
disaster"?) for things that you can't legitimately put in portable code,
but that are guaranteed not to slip by undetected if you do.
I may not be able to get people to agree that certain errors should be
signalled if I ask for safety, though they may not be caught if I ask
for speed. But I don't think we ought to adopt terminology that would
make it impossible even to propose this.
I want to voice strong support for the point of view Jonathan is expressing
here. ``Signalling an error'' does not make a program undefined unless the
program fails to handle the error. Currently there is no way to distinguish
these since you can't handle errors, but in my new condition system, there
will be. ``Is an error'' does make a program undefined since it doesn't say
what action will be taken.
This is a very tricky topic to talk about. New terminology is necessary
and that means the imposition of arbitrary additional semantics on seemingly
normal words. My Exceptional Situations paper (X3J13/86-011) develops the
topic very carefully, distinguishing between exceptional situations (which
span both ``is an error'' and ``signals an error'') and conditions (which
refers only to detected errors). I would appreciate it if you (and the others)
could take the time to (re)read at least the first 4 pages -- up to and
including section IV -- if not the entire document. I think that it
establishes some useful terminology which if we all shared would make some
of this discussion easier on Sunday.
∂15-Mar-87 1631 masinter.pa@Xerox.COM the issues file currently -- take your pick
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 16:30:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 16:31:25 PST
Date: 15 Mar 87 16:31 PST
From: masinter.pa@Xerox.COM
Subject: the issues file currently -- take your pick
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-163125-1963@Xerox>
This file contains a list of issues and proposals for the X3J13 cleanup
committee to consider. It is broken into several sections, divided by a
line of ='s.
* Simple clarifications: items that are unclear, contradictory, or
underspecified in CLtL. In these cases, the proper fix seems obvious.
* Complex clarifications: these may require a bit more discussion.
* Simple changes: proposed small changes that may or may not be
desirable.
* Complex changes: these are more complex or fundamental changes that
will probably require extensive discussion. Some of them require the
development of a specific proposal.
* Proposed additions: these are additions or compatible extensions that
may or may not be worth adding to the language. Some of them require
the development of specific proposals. In general, these are less
urgent than the clarifications and proposed changes.
* Issues to pass along to the compiler committee.
The clarifications on Steele's list of Jan, 1986, are included here
except for those that have been withdrawn or extensively modified by
later discussion. The initial judgements about which issues are simple
and which are complex were made by Scott Fahlman, who has frequently
been wrong about such things in the past.
This file does not currently reflect proposals made after the August
1986 Lisp conference. The formal proposals discussed just before the
Lisp conference are included here, more or less as place-holders. I
have not yet dug through the relevant mail to find all of the options
and amendments that were proposed in the course of discussion.
The plan is to have the "cleanup" subcommittee of X3J13 turn these
issues into a series of proposals that will be sent to the Clisp mailing
list for comment, then to the full X3J13 committee, which will consider
whether to include these changes in the forthcoming Common Lisp
standard.
Note well: These are just preliminary proposals, which may change or be
rejected. Anyone who makes use of these things prior to their formal
approval by X3J13 does so at their own risk.
===========================================================================
SIMPLE CLARIFICATIONS:
---------------------------------------------------------------------------
Page 295:
Specify that ADJUST-ARRAY is another important exception to the general
rule about operating only on active elements of arrays. (See proposed
clarifications of ADJUST-ARRAY.)
[ Benson: Also include SETF of AREF, ROW-MAJOR-AREF, and SETF of
ROW-MAJOR-AREF among the functions which can access beyond the fill pointer
of an array. ]
---------------------------------------------------------------------------
Page 297:
Specify that the fill pointer is ignored for the purposes of deciding
whether a given element of a new array resulting from ADJUST-ARRAY
should take its value from the old array contents or from the specified
:INITIAL-ELEMENT.
---------------------------------------------------------------------------
Page 307:
Allow a call to DEFSTRUCT to have no slot-descriptions.
Specify that it is an error for two slots in a single DEFSTRUCT to have
the same name. If structure A includes structure B, then no additional
slot of A may have the same name as any slot of B.
[Subsumed by the object proposal?]
---------------------------------------------------------------------------
Page 322:
At end of second paragraph on *APPLYHOOK*, clarify that the apply hook
function is not used when special forms are evaluated.
[Radical alternative: Flush *applyhook* and *evalhook*, as suggested in the
CHANGES file.]
---------------------------------------------------------------------------
Page 328:
Remove the requirement that *STANDARD-INPUT*, etc., must be initially
bound to synonym streams to *TERMINAL-IO*; demote this to the level of
an implementation suggestion. This is to allow flexibility of
implementation, for example to allow UNIX redirection to win.
---------------------------------------------------------------------------
Page 425:
Generalize FILE-LENGTH to accept any filename, not just an open
file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting
to STRING-CHAR for non-stream arguments and to the element-type of the
stream for a stream argument.
---------------------------------------------------------------------------
Page 439:
Clarify that if DISASSEMBLE is given a symbol whose function definition
is interpreted, that definition is indeed compiled and then
disassembled, but the resulting compiled definition does not replace the
interpreted one as the symbol's function definition.
---------------------------------------------------------------------------
Page 443:
Modify description of APROPOS to replace the words ``available in'' to
``accessible in,'' and specify that APROPOS on a given package finds the
same symbols that DO-SYMBOLS would.
---------------------------------------------------------------------------
Page 268:
The doc for APPEND should be clarified to warn the user that APPEND
can return a non-list, e.g. (append '() t) => t.
Also, the doc for NCONC should be clarified so that NCONC behaves
analogously to APPEND when its last argument is an atom.
---------------------------------------------------------------------------
Throughout: Adopt the term "special operator" for the symbol that
introduces a special form, leaving "special form" to refer to the whole
form. This would require renaming SPECIAL-FORM-P to SPECIAL-OPERATOR-P.
---------------------------------------------------------------------------
Page 305:
Clarify: The default value in a defstruct slot is not evaluated unless it
is needed in the creation of a particular structure instance. If it is
never needed, there can be no type-mismatch error, even if the type of the
slot is specified, and no warning should be issued.
---------------------------------------------------------------------------
Page 418:
Specify the default for :IF-DOES-NOT-EXIST if :DIRECTION is :PROBE.
[Should probe even be a direction or was that a bad idea?]
---------------------------------------------------------------------------
Page 246:
Specify that it is an error for the SUBSEQ indices or any :START or :END
argument have a negative index or point past the end of the sequence in
question. (With respect to whether signalling is required, this error will
be treated the same as array out-of-bounds.)
---------------------------------------------------------------------------
Page 379:
Specify that PEEK-CHAR operations on echo streams should not echo. The
echo occurs when the character is actually read. (We may have to add "on
systems which can manage this", since there may be some that cannot.)
---------------------------------------------------------------------------
Page 404:
Specify that the ~< ... ~> directives to FORMAT divide the whitespace
evenly into the gaps between the units of text. Any remaining quanta of
whitespace are distributed into gaps from left to right, not placed
randomly.
---------------------------------------------------------------------------
Page 274:
Clarify by example that NSUBST-IF-NOT is perhaps non-intuitive:
(let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
(new (nsubst-if-not '3.1415 #'numberp item-list)))
(values new item-list))
=> 3.1415
(NUMBERS (1.0 2 5/3) SYMBOLS (FOO BAR))
---------------------------------------------------------------------------
Page 140:
Clarify that in an UNWIND-PROTECT, the cleanup forms are executed in the
dynamic environment of the UNWIND-PROTECT itself.
---------------------------------------------------------------------------
Page 113:
Clarify that the bindings created by FLET and LABELS have lexical scope
and indefinite extent. The functions themselves have indefinite extent.
---------------------------------------------------------------------------
Page 51:
Clarify that coerce MAY NOT copy the argument if it is already of the
correct type. (At present, the manual is inconsistent on whether a copy
is allowed.)
---------------------------------------------------------------------------
Page 426:
Make explicit that when a compiled file is loaded, symbols naming
lexical variables in the code may or may not be created. This is left up
to the implementation.
---------------------------------------------------------------------------
Page 426:
Clarify what the :VERBOSE and :PRINT options to LOAD do, or at least what
their intent is.
One proposal, by SEF:
1. Load with no switches should not print anything on standard-output.
2. The :verbose switch is intended to print some per-file information
and an indication when the loading is done, but not something for every
form that is loaded.
3. The :print switch is intended to cause the read/eval/print loop's
output to be printed, or if the file is compiled, something for each
form that is loaded.
4. These are only guidelines covering the intent of how these switches
are to be used. Implementations are free to indicate this kind of
information in other ways if that makes sense in their environment.
---------------------------------------------------------------------------
Page 67:
Clarify that argument-list init-forms are NOT lexically within the block
established by the Defun of which they are a part. (Most implementations
have done it this way.)
---------------------------------------------------------------------------
Page 422:
Clarify that WITH-OPEN-FILE returns the value(s) of the last form in the
body.
---------------------------------------------------------------------------
Page 200, 215:
Clarification: Division by 0 should be documented to be an error. It
doesn't seem to be at present.
[For flonums, maybe allow IEEE-type infinities here. Wait for error
proposal before discussing whether error must be signalled and how.]
---------------------------------------------------------------------------
Page 50, 307:
Clarification: It is an error to redefine an built-in type via DEFSTRUCT or
DEFTYPE. [Coordinate with object proposal.]
---------------------------------------------------------------------------
Page 316:
Clarify that if a defstruct specifies a BOA constructor, the default
keyword-style constructor is not also defined. (OR clarify that it is.)
---------------------------------------------------------------------------
Page 280:
Clarify that the :KEY argument to ASSOC is applied to the car of each list,
not the whole pair.
---------------------------------------------------------------------------
Page 104:
In the description of the second value of a setf method:
A list of *value forms* (subforms of the given form) to whose values
the temporary values are to be bound.
preface the parentheical remark with "often" or "usually". It is not
always true, as in the following example:
(DEFMACRO ELT-IF (SEQ PRED IND1 IND2)
`(ELT ,SEQ (IF ,PRED ,IND1 ,IND2)))
The setf method of (ELT2 S P A B) is defined to be the same as that of
(ELT S (IF P A B)). There is no way to express the setf method of this
form in terms of the values of subforms of (ELT2 S P A B), since A and
B are not always evaluated. In the implementations I have checked, the
setf method of (ELT2 S P A B) has value forms S and (IF P A B).
The current statement is also harmful if read as a prescription for
DEFINE-SETF-METHOD, since it is then impossible to define SETF methods
for forms that do not always evaluate all of their arguments.
---------------------------------------------------------------------------
Page 130:
Specify that constant forms such as strings may appear at top-level in a
tagbody, but that only symbols and integers are considered to be tags.
It is an error to use anything else as the destination tag for a GO.
Specify that it is an error for the same (EQL) tag to appear more than
once in the body of a TAGBODY. (However, a TAGBODY may have the same
tag as another TAGBODY in which it nests, in which case the tag in the
outer TAGBODY is shadowed, as already specified.)
===========================================================================
COMPLEX CLARIFICATIONS:
---------------------------------------------------------------------------
Page ???:
It is not specified what happens when the same (EQL) variable appears more
than once in a lambda-list or binding form (LET, LET*, etc.). This was
discussed at some length in June/July 1986. Possible options:
1. It is an error.
2. Latest (rightmost) binding governs in all forms.
3. It is an error in parallel-binding forms and lambdas, but rightmost
governs in serial-binding forms such as LET*.
[Related issue: special dispensation to allow multiple uses of ignored
variables? Bring back IGNORE as a universally-ignored variable?]
---------------------------------------------------------------------------
Page 68:
Clarify that using DEFCONSTANT to redefine any constant described in the
Common Lisp specification is an error.
Clarify that if the user defines a constant, compiles code that refers
to that constant, and then redefines the constant, then behavior of the
compiled code may be unpredictable. It is an error to execute such
code.
Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
[Needed for reloading compiled code files.]
---------------------------------------------------------------------------
Page ???:
Clarify the whole mess surrounding functions, function names, compiled
functions, closures, FUNCTION, and related predicates. Are lambda
expressions function-objects or function-names? Should (functionp foo)
be equivalent to (typep foo 'function) ? Is (typep foo 'function)
legal? Must the value of SYMBOL-FUNCTION be a function?
[Need a comprehensive proposal on this one. A move to Lisp1 would
change all this, but we should clarify it for the current Lisp2.]
---------------------------------------------------------------------------
Page 413, 424:
The semantics of TRUENAME and PROBE-FILE on open streams
needs to be clarified. The requirement that PROBE-FILE never return
NIL on an open file is clearly broken. Spice Lisp currently
implements TRUENAME and PROBE-FILE in the same way, except that
TRUENAME errors instead of returning NIL. Someone (Moon, I believe)
suggested that (PROBE-FILE <stream>) was the same as
(PROBE-FILE (PATHNAME <stream>)), but that (TRUENAME <stream>) was
somehow different. There also needs to be some discussion of the
meaning of operations on closed streams. The manual never says which
operations may be done on closed streams, let alone what the
operations do.
---------------------------------------------------------------------------
Page ???:
Define carefully which returned values may be shared structure. These
must not be destructively modified (or should be copied if you want to
be safe). Symbol name-strings, rest-arg lists...
---------------------------------------------------------------------------
Page 93:
Clarify that MACROLET shadows any setf function for the associated macro:
(DEFUN LOSER (X)
(CAR X)
(DEFUN SET-LOSER (X Y)
(SETF (CAR X) Y))
(DEFSETF LOSER SET-LOSER)
(DEFUN LOSSAGE (X Y)
(MACROLET ((LOSER (X)
`(SYMBOL-VALUE ,X)))
(SETF (LOSER X) Y)))
LOSSAGE calls SET, not SET-LOSER.
---------------------------------------------------------------------------
Page 113:
Clarify that FLET shadows DEFMACRO.
---------------------------------------------------------------------------
Page 321:
Modify EVAL to have an optional environment argument.
[I think this is unwise. -- SEF]
---------------------------------------------------------------------------
Page 440:
Specify explicitly that one may trace macros as well as functions.
[Is this feasible in all implementations?]
---------------------------------------------------------------------------
Page 80:
Clarify what EQUAL and EQUALP do on structures. Proposal: If the
structures are of the same type, both EQUAL and EQUALP do component-wise
comparison.
---------------------------------------------------------------------------
Page 112:
Clarify Compiler-Let or flush it. [SEF: Flush it.]
---------------------------------------------------------------------------
Page 389:
Need a portable way to print a #\SPACE as " ". (FORMAT NIL "~C"
#\Space) may or may not do this. Same with PRINC. For Standard
characters, it is safe to be more specific about how things are printed.
---------------------------------------------------------------------------
Page 160:
Either specify that IGNOREd arguments do not generate a warning if you
use them after all, or add a new declaration IGNORABLE.
[Stupid issue, discussed to death earlier.]
---------------------------------------------------------------------------
Page 295:
Proposed clarifications regarding fill pointers:
If no fill pointer is specified to Make-Array, the implementaiton is
not required to supply a fill-pointer, but may do so.
If a destructive sequence function such as DELETE is passed an array
with a fill pointer, it may change the active size of the array by
manipulating the fill pointer; it is not required that the underlying
array's ARRAY-DIMENSION be altered.
If ADJUST-ARRAY is called on a vector with a fill pointer, but is not
given a :FILL-POINTER argument, the fill-pointer is retained and is
reset to the new length of the vector.
---------------------------------------------------------------------------
Page 249 and elsewhere:
What is the effect of giving circular lists to MAP, MAPCAR, SOME,
EVERY, etc.? Specify that it is an error, or require it to work?
[ There's a real split on this issue. To some people, circular lists
are a clever hack and this obviously should work. To others, they are
an evil that should not be encouraged. SEF and GLS have argued in favor
of treating this as an error. ]
---------------------------------------------------------------------------
Page 448:
Proposal by Moon for clarification to features: The "feature expression"
after a #+ or #- is read in the keyword package if no explicit package
prefix appears in it, but it is legal to use an explicit package prefix.
Features defined in the Common Lisp manual are in the keyword package,
and "public" features (such as those of a particular implementation) are
in the keyword package, by convention. "Private" features can be
qualified with a package name when that convention seems appropriate.
(Proposed by KMP:) Package failure while reading a feature name is
equivalent to nonpresence of that feature, rather than being an error.
Thus (list 1 #+(not nosuchpackage:quux) 2 3) evaluates to a list of 3
elements in most circumstances.
---------------------------------------------------------------------------
Page 307:
Does COPY-FOO (where foo is a structure) work on subtypes that include
FOO? Does COPY-PERSON work on ASTRONAUT?
[Subsumed by object proposal? Gregor suggests: COPY-xxx as defined by a
defstruct returns a structure of that defstruct's type. COPY returns a
structure of the same type as its argument.]
---------------------------------------------------------------------------
Page 152:
Clarify (figure out) how MACROLET and *MACROEXPAND-HOOK* interact.
---------------------------------------------------------------------------
Page 447:
Clarify by example what sort of thing goes into
LISP-IMPLEMENTATION-TYPE, etc.
---------------------------------------------------------------------------
Page ???:
Clarify the ways in which an implementation may extend pure Common Lisp:
Extra keywords to specified functions? To all functions? Extra return
values? Functions working on otherwise illegal types? Require a compiler
mode that catches non-Common stuff? Should we document certain specific
functions (e.g. COMPILE) as allowing implementation-specific keyword
extensions.
---------------------------------------------------------------------------
Chapter 23:
Pathnames and the file system interface require much clarification and
probably some changes. A comprehensive proposal is needed here.
The Symbolics solution might work for us. If we can't fix this up, we
should consider dumping the whole thing and going with something very
simple and minimal, such as a raw string in system-specific format to
designate a file.
---------------------------------------------------------------------------
Page 145:
Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
---------------------------------------------------------------------------
Page 60:
Decide whether an &rest arg is required to be a freshly-consed list or
whether it may be part of a pre-existing list passed in by APPLY.
---------------------------------------------------------------------------
Page 162:
Decide what the behavior of (THE (VALUES ...) form) should be. Does it
specify exactly how many values should be returned, or a lower limit, or
what?
One proposal: in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and any extra values are of unrestricted type.
Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).
[Discussed June/July 1986.]
===========================================================================
SIMPLE CHANGES:
---------------------------------------------------------------------------
Page 239:
Change CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP,
CHAR-NOT-LESSP, and CHAR-NOT-GREATERP to consider two characters to be
different if their bits attributes are different.
[May be subsumed under a wholesale redesign of character objects,
eliminating the BIT and FONT attributes.]
---------------------------------------------------------------------------
Page 202:
Define (LCM) to return 1 (the manual is incorrect in claiming that the
result should be infinity).
---------------------------------------------------------------------------
Page 377:
Extend READ-DELIMITED-LIST by adding one more optional argument,
dot-permitted-p, defaulting to nil, that if true allows the delimited list
to contain dot notation, and if false forbids dot notation.
---------------------------------------------------------------------------
Page 323:
Eliminate the ENV argument to APPLYHOOK, which is useless.
---------------------------------------------------------------------------
Page 418:
Flush :DIRECTION :PROBE.
---------------------------------------------------------------------------
Page 171 ff:
All functions that take a package as an argument, except those
named PACKAGE-xxx, will also take a string or symbol and do an implicit
find-package. This gives users maximum flexibility and minimum confusion.
---------------------------------------------------------------------------
Page 316:
BOA constructors take keywords, with the obvious semantics.
---------------------------------------------------------------------------
Page 251:
(reduce #'+ list-of-objects :KEY #'object-quantity) would apply the
function OBJECT-QUANTITY to each element of the list-of-objects before
reducing it with +.
---------------------------------------------------------------------------
Page 327:
Functions that require a string, pathname, stream, or symbol
should not accept a symbol. NIL is confusing, and some implementations
use symbols for certain streams. [Proposal by Moon]
---------------------------------------------------------------------------
Page 305:
Require that structures (created without the :TYPE specifier) are
disjoint from the other built-in types such as vector? They already
must be distinguishable from plain old vectors.
---------------------------------------------------------------------------
Page ???:
Forbid implementations to produce unsolicited output to
*standard-ouput*. Output to *error-ouput* is always OK.
---------------------------------------------------------------------------
Page 444:
In the description of Decoded Time format, the Time-zone component is
required to be an integer which is the number of hours west of GMT.
(The latest term is Coordinated Universal Time, or UTC, by the way).
Since time zones are not always an integral number of hours west of GMT,
this should be changed to either (a) a non-complex, non-negative number
which is the number of hours west of GMT, or (b) an integer which is the
number of {minutes, seconds} west of GMT.
===========================================================================
COMPLEX CHANGES:
---------------------------------------------------------------------------
Page 210:
Change the branch cuts of the ATAN function to follow W. Kahan's
recommendations. (Paul Penfield intends to recommend the same change to
the APL community.)
[Steele should produce a specific proposal without forwarding pointers.]
---------------------------------------------------------------------------
Page 181:
There must be a package with only the official Common Lisp symbols,
either named LISP or COMMON-LISP. Work out where
implementation-specific extensions go. Several proposals exist.
---------------------------------------------------------------------------
Page 80:
EQUAL should descend into arrays, if they are the same type and
dimensionality, comparing leaves by EQL.
[SEF: I was partly to blame for the decision not to do this. I now
believe that we blew it here, and should consider un-blowing it. The
change will break some code, but the community might accept it anyway.]
---------------------------------------------------------------------------
Page 26, 42:
Alter the LIST type-specifier to distinguish proper lists from others and
to specify the element-type of the list.
---------------------------------------------------------------------------
Page 93:
Flush MACROLET, thereby doing away with environment arguments and related
confusion.
[This has been proposed N times and rejected each time on the grounds that
MACROLET is not *totally* useless, but I still think that this is the right
thing to do. -- SEF]
---------------------------------------------------------------------------
Page 154:
Eliminate the provision that a macro at the start of a body may expand
into a declaration.
[KMP, who was one of the more vocal proponents of this feature, has
now suggested that we consider flushing it. It requires some confusing
environment hackery to do this right.]
---------------------------------------------------------------------------
Page 322:
Flush *applyhook* and *evalhook* and related hackery. Does anyone use
this (correctly) for anything other than implementing steppers? If not,
it may be preferable to forget about portable stepper hooks and make
stepping an implementaiton-dependent facility like DEBUG. These hooks
cause an awful lot of confusion and anxiety for users and implementors.
---------------------------------------------------------------------------
Page 153:
Proposed alterations to SPECIAL declaration and possible addition of
UNSPECIAL (see Common Lisp mail around July 1986 including proposal by
Pavel). One or more coherent proposals have to be constructed for
consideration.
---------------------------------------------------------------------------
Page 58:
Turn the warning that standard macros should not expand into
non-standard special forms into a requirement. Makes life easier for
code-walkers.
[Can all implemenations live with this?]
---------------------------------------------------------------------------
Page ???:
Two related, controversial proposals on case-sensitivity for symbols:
Add a switch that would tell read and friends to suppress case
conversion, along with a note indicating that portable code assumes this
switch to be OFF.
[SEF: This is the proposal dear to the unix people. I still think that
it is asking for trouble to put this in. Some code will assume this
switch despite the warning, some won't, and the two kinds of code will
not mix.]
Alternatively, think again about making the language case-preserving,
but with INTERN ignoring case completely. This means that there is *NO*
way to create two symbols, one named "FOO" and the other named "foo",
but now that we have strings this may not be necessary.
[SEF: I now believe that this is what we should have done, but it is
probably too radical a change to consider at this point.]
---------------------------------------------------------------------------
Page 171:
Even if we keep the status quo for symbols, we may want to reconsider
the rules on case-sensitivity for package names. Need a specific
proposal and analysis of transition strategy.
---------------------------------------------------------------------------
Page ???:
In addition to DEFUN, the following macros implicitly wrap a BLOCK
around their bodies: DEFMACRO, DEFSETF, DEFINE-SETF-METHOD, and DEFTYPE.
Also, LABELS, FLET amd MACROLET should wrap a block around the bodies of
the locally defined functions. Users are encouraged to create such
blocks in their own macros where a body and an obvious block-name are
present.
[SEF: I think I am opposed to this one. It is a convenience for the
programmer, but it either adds considerable complexity to the
interpreter or requires a code walk and modification of code internals
at DEFUN time. It also tends to interfere with certain optimizations,
such as tail-recursion removal.]
---------------------------------------------------------------------------
Page ???:
DEFGLOBAL or some other mechanism for global lexicals.
[Discussed earlier, with several proposals and no clear winner. This
change is believed to be essential if we go with Lisp1 model, and may be
worth the trouble in any event. There might be some way to phase it in
smoothly.]
---------------------------------------------------------------------------
Page 382:
How to communicate the current depth in printing when there are
user-defined print functions? Guy said that what had in mind was that
the user would bind *print-level* according to the depth arg supplied to
the print function, but there were several problems with this. Most of
the tasteful solutions involved adding new args to WRITE which indicated
the nature of the recursive use of the printer. Others objected that
nobody wants to use WRITE directly, so that isn't a real fix.
---------------------------------------------------------------------------
Chapter 13:
We need a comprehensive proposal for handling extended characters
(16-bit char-code, plus possibly other fields) and strings of extended
characters. The Japanese are developing a Kanji standard. Maybe we
can just adopt this; certainly we must coordinate with it.
At the same time, consider whether to retain the char-bit and char-font
fileds in present form. Since an implementaiton may omit these fields,
this should not break truly portable code.
===========================================================================
PROPOSED ADDITIONS:
---------------------------------------------------------------------------
Page ???
Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time.
---------------------------------------------------------------------------
Page 226:
Add SIGNED-LDB. Like LDB but sign-extends the extracted byte.
---------------------------------------------------------------------------
Page 283:
Add functions HASH-TABLE-REHASH-SIZE, HASH-TABLE-REHASH-THRESHOLD,
HASH-TABLE-SIZE, and HASH-TABLE-TEST each take a hash table and return
the appropriate current information.
[ Which, if any, are SETF-able? What does hash-table-test return, the
function object for the test function? ]
---------------------------------------------------------------------------
Page 293:
Add a function ROW-MAJOR-AREF, taking an array and a single
subscript, that accesses an array element according to the row-major
ordering. Add a function DISPLACED-ARRAY-P, which takes an array and
returns NIL and 0 if it is not displaced or the array displaced to and
the displaced-index-offset if it is displaced. These allow certain code
efficiencies, and also allow array displacement to be explained in
terms of Lisp primitives:
(DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS)
(LABELS ((FOO (ARRAY INDEX)
(MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY)
(IF (NULL NEW-ARRAY)
(ROW-MAJOR-AREF ARRAY INDEX)
(MULTIPLE-VALUE-CALL #'FOO
NEW-ARRAY
(+ INDEX OFFSET)))))
(FOO ORIGINAL-ARRAY
(APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS))))
As a bow to efficiency, note the fact that if array A is displaced to B
with offset M, and B is displaced to C with offset N, and B is not
adjustable, then DISPLACED-ARRAY-P of A might return either array B with
offset M or array C with offset (+ M N). This generalizes to chains
of non-adjustable arrays.
[Benson suggests that ROW-MAJOR-AREF be SETFable.]
---------------------------------------------------------------------------
Page 439:
Add COMPILEDP. This takes a function and returns non-NIL if it is a
compiled function, and NIL if it is not. If the function is a symbol
whose compiled-function definition was installed by the COMPILE
function, then the non-NIL value returned is the interpreted definition
that was compiled.
---------------------------------------------------------------------------
Page 439:
Add UNCOMPILE. This takes a symbol and restores the previous
interpreted definition of that symbol if that symbol previously had an
interpreted definition and was then given to COMPILE; otherwise no
action is taken.
---------------------------------------------------------------------------
Page 447:
Add USER-NAME. This returns a string identifying the user of the Common
Lisp system, or NIL if that cannot be determined.
---------------------------------------------------------------------------
Page 327:
Add *DISCARD-OUTPUT-STREAM* (alias, the bit bucket).
[Make this a constant so that it can be optimized? You should never want
to rebind this to another value.]
---------------------------------------------------------------------------
Page 117:
Add (CASE-WITH-TEST test item ...clauses...).
---------------------------------------------------------------------------
Page 51:
Extension: Let COERCE coerce symbols to strings. NIL is treated as the
empty sequence, not a symbol. Also let COERCE turn string-chars into
strings of length 1.
---------------------------------------------------------------------------
Page ???:
Add TRUE and FALSE, functions that take any number of args, ignore them,
and return T and NIL respectively.
Someplace:
---------------------------------------------------------------------------
Page ???:
Add a special form (LOAD-TIME-EVAL form). This gives program-generated
code access to the functionality of #, .
---------------------------------------------------------------------------
Page 95, 267:
Add SETF of NTHCDR.
---------------------------------------------------------------------------
Page 158:
Add a TYPE-RESTRICT declaration. (TYPE-RESTRICT type1 type2), where
type2 is a subtype of type1, says that within the scope of the
declaration if the compiler can prove a value is of type1, it is
allowed to assume that it is of type2. This gets rid of a lot of
multiple-THE forms when you want maximally tense code.
---------------------------------------------------------------------------
Page 73:
Fill out the set of mumble-P type predicates. Currently we have some
and not others.
---------------------------------------------------------------------------
Page ???:
We need a set of "undoing" functions, so that interactive errors and
failed experiments can be recovered from without starting over.
See comprehensive proposal by Eric Benson.
[SEF: A generic "undo" facility, like SETF, has been opposed on various
occasions, but is a bad idea because users will expect too much of it,
and complain when it doesn't undo everything.]
---------------------------------------------------------------------------
Page 336:
Add (syntax-type <character>), which returns one of the following:
:illegal, :whitespace, :constituent, :single-escape, :multiple-escape,
:terminating-macro, :non-terminating-macro.
[Make this setf-able? If so, what do we do about macro characters that
have no definitions?]
---------------------------------------------------------------------------
Page 283:
Add EQUALP hash-tables? Case-insensitive hash-tables for strings? Let
the user provide his own test (with associated hashing function)? [Need
a coherent proposal.]
---------------------------------------------------------------------------
Page ???:
Have a function COPY that can copy any single object. For a CONS cell
it would copy just that CONS. Whether (EQ X (COPY X)) for X a character
or number is implementation-dependent.
[Proposal in archives by Morrison, needs some tuning.]
---------------------------------------------------------------------------
Page 171:
We need a way to say "use all the symbols from package FOO except for X,
Y, ..." Shadowing is no good, since you might want to inherit X from
somewhere else. Also, do we want a make-package that says ALL symbols
get exported?
---------------------------------------------------------------------------
Page ???:
Fahlman's proposal for &more arguments, similar to &rest but leaves the
arguments on the stack LEXPR-style. Removes one of the worst inherent
efficiency problems in Common Lisp.
---------------------------------------------------------------------------
Page 438:
Review and develop a general philosophy on the handling of semi-standard
system interface functions such as GC, BYE, ED, SAVE-SYSTEM, etc. Then
see what we want to add (or remove).
---------------------------------------------------------------------------
Page ???:
Consider FUNCTION-PARAMETERS and related proposals that were discussed
extensively in June/July 1986.
---------------------------------------------------------------------------
Page ???:
Consider PARSE-BODY and extended syntax for &BODY, as discussed in
June/July 1986.
[Note, if we flush MACROLET or eliminate macro-expansion into
declarations, this extension becomes less critical, though it may still
be useful.]
---------------------------------------------------------------------------
Page 154:
Permit declarations before the body of a LABELS, FLET, or MACROLET.
===========================================================================
For the compiler committee:
---------------------------------------------------------------------------
A lot of compiler/eval-when issues need to be settled. Among the
issues: Define clearly how REQUIRE interacts with the compiler. Are
DEFSETF-generated available in the compiler environment by default?
---------------------------------------------------------------------------
Package interactions with COMPILE and LOAD need to be worked out better.
Restrict IN-PACKAGE, IMPORT, and firends to the start of files only?
Add a new declarative form to handle this? Some favor legitimzing -*-
forms, but this is unacceptable to many.
---------------------------------------------------------------------------
Related issue: Add INCLUDE, or some other way to stuff multiple source
files into one binary? (Package hackery makes this complicated.)
---------------------------------------------------------------------------
Related issue: There should be some discussion of the semantics of
compilation on literal constants (things appearing in quoted structure
in code). To what degree is sharing and non-sharing preserved? Many
implementations both introduce and remove sharing. Probably most don't
dump circular structures.
---------------------------------------------------------------------------
What things can a compiler optimize by inline expansion, tail-recursion
elimination, etc.? What things must be handled correctly if the user
redefines a built-in function (or specializes it using the object
facility)?
Proto-proposal: All built-in functions may be optimized inline
(and therefore do not respond to later modifcation) unless this is
inhibited with a NOTINLINE declaration. Maybe create a list of
functions such as PRINT that are not open-coded by default. Also,
within a DEFUN, a recursive call to the function being defined may be
optimizied into a jump, unless this is inhibited by NOTINLINE. (Maybe
think up a better term than NOTINLINE.)
---------------------------------------------------------------------------
NEW:
Declare *print-circle* means to print out shared structure too. Alternative: add another variable *print-shared*. Alternative: add another value to *print-circle* (nil :none t :unspecified :circular :shared).
∂15-Mar-87 1638 masinter.pa@Xerox.COM additional topics
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 16:38:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 16:39:24 PST
Date: 15 Mar 87 16:39 PST
From: masinter.pa@Xerox.COM
Subject: additional topics
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-163924-1968@Xerox>
From RPG's notes at the meeting:
Issues left to consider
1. Does the implicit BLOCK in a DEFUN contain the optional default computation,
the &AUX computation, etc?
2. Require LABELS to obey tail-recursive semantics.
3. Eliminate implicit BLOCK from DEFUN.
∂15-Mar-87 1848 masinter.pa@Xerox.COM released: compiler-warning-stream
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 18:48:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 18:49:06 PST
Date: 15 Mar 87 18:48 PST
From: masinter.pa@Xerox.COM
Subject: released: compiler-warning-stream
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-184906-2023@Xerox>
This is the latest revision of the compiler-warning-stream proposal.
Status: Released.
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Revision 2 at committee meeting 15-Mar-87 14:18:56
Revision 3 reformat by Masinter 15-Mar-87 17:42:10
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The cleanup committee supports this change.
∂15-Mar-87 1849 masinter.pa@Xerox.COM Issue format-atsign-colon
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 18:49:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 18:50:18 PST
Date: 15 Mar 87 18:50 PST
From: masinter.pa@Xerox.COM
Subject: Issue format-atsign-colon
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-185018-2024@Xerox>
This is the latest version of the format-atsign-colon proposal.
Status Released
Issue: FORMAT-ATSIGN-COLON
References: FORMAT description (p386)
Category: CLARIFICATION
Edit history: Revision 1 by KMP 02/27/87
Revision 2 by cleanup committee 15-Mar-87 14:50:50
Revision 3 by Masinter 15-Mar-87 18:37:23
Problem Description:
CLtL describes the format op syntax as:
"a format directive consists of a tilde (~), optional prefix parameters
separated by commas, optional colon (:) and atsign (@) modifiers, and a
single character indicating what kind of directive this is."
CLtL uses :@ fairly consistently throughout without saying whether @: is
legal. Is @: allowed?
Proposal (FORMAT-ATSIGN-COLON:OK):
There is no required ordering between the @ and : modifier.
Rationale:
This is currently underspecified, and this way of specifying it will
cause the least disruption to user code.
Current Practice:
Most implementations accept these in either order. Some implementations
have been known to expect only :@.
Adoption Cost:
The change to accept either syntax is probably quite trivial.
Benefits:
Having @: and :@ mean different things would be awkward.
Conversion Cost:
Existing user code would be unaffected.
Aesthetics:
Leaving these unordered is slightly simpler conceptually.
Discussion:
The cleanup committee supports this clarification.
∂15-Mar-87 1850 masinter.pa@Xerox.COM Format for issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 18:50:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 18:51:03 PST
Date: 15 Mar 87 18:51 PST
From: masinter.pa@Xerox.COM
Subject: Format for issues
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-185103-2027@Xerox>
This is the latest version of the format for submission of issues.
Format for proposals to "clean up" Common Lisp.
Revision 7 - 15-Mar-87 17:48:09
General notes: Replace the text in italics. Be brief; leave testimonials
and personal opinions to the discussion at the end. Be complete; do not
expect someone else to fix or redesign something.
Issue: A short descriptive label. Your label should start with a name
which occurs in the index of CLtL, and be a suitable symbol in the
Common Lisp style, e.g., CDR-TERMINATION. Avoid one-sided-titles, e.g.,
FORMAT-BROKEN. Issue names will be formally assigned, but you make make
up a provisional title.
References: The pages of CLtL which describe the Common Lisp feature
being discussed, if such a reference exists. Other references where
appropriate.
Category: One or more of the following:
CLARIFICATION - proposal to resolve an ambiguity or case of
under-specified situation in CLtL, where this ambiguity interferes with
portability of code.
CHANGE - Proposal for an incompatible change to the language.
ADDITION - Proposal for a compatible extension to the language.
Edit history: Original author and date of submission, and author and
date of subsequent revisions. Include version number, starting with
version 1.
Problem description:
Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here.
Proposal (issue-label:proposal-label):
Describe as precisely as possible what you are proposing. Ideally, this
should take the form of text that could be dropped into CLtL or some new
specification document. You may propose a set of numbered alternatives
here, rather than one single proposal. Each proposal must be a complete
design; do not leave out details. Avoid arguing for the proposal here,
just describe it.
Test Case:
When possible, give a sample of Common Lisp code which illustrates the
issue.
Rationale:
Note: if more than one proposal is listed, provide the information
requested separately for each choice. The rationale is a brief
explaination of why this is a good proposal.
Current practice:
Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more.
Adoption Cost:
What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?
Benefits:
What is better if the proposal is adopted? How serious is the problem if
just left as it is?
Conversion Cost:
For incompatible changes, what is the cost of converting existing user
code? To what extent can the process be automated?
Aesthetics:
How does this proposal affect the simplicity of the language, ease of
learning, etc.
Discussion:
Any additional arguments, discussions, endorsements, testimonials, etc.
should go here.
∂15-Mar-87 1853 masinter.pa@Xerox.COM Issue IMPORT-SETF-SYMBOL-PACKAGE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 18:53:29 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 18:52:17 PST
Date: 15 Mar 87 18:52 PST
From: masinter.pa@Xerox.COM
Subject: Issue IMPORT-SETF-SYMBOL-PACKAGE
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-185217-2030@Xerox>
This is the latest version of the IMPORT-SETF-SYMBOL-PACKAGE proposal.
Status RELEASED
Issue: IMPORT-SETF-SYMBOL-PACKAGE
References: CLtL p. 186
Category: CLARIFICATION.
Edit History: Revision 2 at committee meeting 15-Mar-87 15:19:23
Revision 3 by Masinter 15-Mar-87 18:42:13
Problem Description:
The action of IMPORT on the home package of a symbol is not described
well; does it affects the "home package" of a symbol.
Proposal (IMPORT-SETF-SYMBOL-PACKAGE:YES)
IMPORT behaves as follows: if any symbol to be imported has no home
package (SYMBOL-PACKAGE returns NIL), then IMPORT sets the home package
of the symbol to the specified package being imported to.
To further clarify: INTERN does not modify the home package of any
pre-existing symbol.
Rationale:
Current practice:
Most Common Lisp implementations work this way.
Adoption Cost:
small -- it requires a simple rewrite if not done this way.
Benefits:
Without this proposal, there is confusion about how Common Lisp works,
and the risks that some new implementations will not work this way.
Conversion Cost:
None, as this describes current practice.
Discussion:
The cleanup committee supports this clarification.
∂15-Mar-87 1855 masinter.pa@Xerox.COM Issue FLET-IMPLICIT-BLOCK
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 18:54:57 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 18:55:44 PST
Date: 15 Mar 87 18:55 PST
From: masinter.pa@Xerox.COM
Subject: Issue FLET-IMPLICIT-BLOCK
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-185544-2035@Xerox>
This is the latest version of the FLET-IMPLICIT-BLOCK proposal. I don't
have a record of who might be working on this.
Status: tabled pending further thought of removing DEFUN implicit block
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Edit history: Revision 2 by cleanup committee 15-Mar-87 15:13:33
Description: Do flet, labels, and macrolet have an implicit block around
their bodies like the body of a DEFUN? CLtL is unclear.
Category: Ommission.
Proposal: FLET-IMPLICIT-BLOCK:YES
FLET, LABELS, and MACROLET have an implicit block around the body with
the same name.
Current Practice:
This does not generally reflect current practice. Several
implementations do not add the implicit block, others do.
Cost of adopting this change:
Small, since adding the implicit block is a simple extension for any
implementation.
Cost of not adopting the change:
Continued inconsistancy between DEFUN-formed functions and FLET defined
functions.
Cost of converting existing code:
Relatively small, in that it is unlikely that any code in a current
implementation that doesn't have an implicit block around FLET code
might also do a RETURN-FROM a block
with the same name.
Test case:
(DEFUN TEST ()
(FLET ((TEST (X) (IF X (RETURN-FROM TEST 4) 3)))
(LIST (TEST NIL) (TEST T))))
(TEST)
will return either (3 4) if this proposal is adopted, and might return 4
if an implementation did *not* add an implicit block.
Discussion:
The goal is consistency between the behavior of global and local
definitions, to make transition between local and global definitions
easy. The alternative is to remove implicit blocks from DEFUN.
---------------------------------------------------------------------------
Another proposal:
In addition to DEFUN, the following macros implicitly wrap a BLOCK
around their bodies: DEFMACRO, DEFSETF, DEFINE-SETF-METHOD, and DEFTYPE.
Also, LABELS, FLET amd MACROLET should wrap a block around the bodies of
the locally defined functions. Users are encouraged to create such
blocks in their own macros where a body and an obvious block-name are
present.
---------------------------------------------------------------------------
Several points and issues:
1. Presumably we want to address DEFMACRO, DEFSETF, DEFINE-SETF-METHOD,
and DEFTYPE at the same time as FLET, LABELS, and MACROLET? Do these
forms raise any issues that are not raised by the others? I don't see
any. Rob tells me that Spice Lisp already installs blocks on all of
these forms additional forms, though we apparently do not do this on
FLET, LABELS, and MACROLET.
2. Do we want to suggest in any new manual that users provide such
blocks for their own macros if they take an arbitrary body? (Presumably
the right way to handle this is for our committee to pass along a set of
non-binding suggestions to the drafting committee. This would be one of
them; the business about avoiding confusing uses of the word "intern"
would be another. That way these suggestions don't get lost, but we
don't have to worry about formal votes tying the drafting committee's
hands in the choice of language.)
3. In the ISSUES file, I say that I think I am opposed to this proposal
on efficiency grounds. I no longer believe this to be a serious
problem. In compiled code, there is no issue: blocks that are not
actually used can be eliminated. I was thinking that this would require
the interpreter to code-walk in and modify FLET, LABELS, and MACROLET
forms at defun time, but clearly this is not the right implementation
strategy. Instead one would modify FLET and friends to establish the
block upon entry. This slows down these forms in the interpreter a bit,
whether the block is used or not, but this slowdown in relatively rare
forms, interpreter only, should not hurt much.
4. Is there an issue here with tail-recursion? Could the presence of
these implicit blocks make it much harder to do tail-recursion
optimization? I don't see the problem now, but I have a note that
someone raised this issue in earlier discussions.
From: Rob MacLachlan <RAM>
In case nobody else answers, the issue with tail-recursion was
that Block in the interpreter cannot mindlessly push things on the
stack if tail recursion is to be preserved. Implementations that
always created catch frames for Block were finding that tail recursion
was being inhibited in Defun due to the implicit block. The fix is to
cons the necessary structure on the heap. Repeated consing can be
avoided by explicitly passing this "continuation" into tail-recursive
invocations of eval.
This issue is almost totally irrelevant in the current discussion,
since the implicit Defun block already causes these problems and
isn't going to go away.
Rob
∂15-Mar-87 1910 masinter.pa@Xerox.COM Issue COMPILER-WARNING-BREAK
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 19:10:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 19:10:47 PST
Date: 15 Mar 87 19:11 PST
From: masinter.pa@Xerox.COM
Subject: Issue COMPILER-WARNING-BREAK
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-191047-2046@Xerox>
This is the latest version of the COMPILER-WARNING-BREAK proposal.
Status: KMP to rewrite, not for release
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Revision 2 by cleanup committee 15-Mar-87 14:25:03
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not say
whether *BREAK-ON-WARNINGS* affects warnings output by the compiler. If
this is to be allowed, it should be an explicitly expressed part of the
contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that these
functions are required to break on warnings if *BREAK-ON-WARNINGS* is
true (just as if it calls WARN).
Note: User interface commands provided by particular vendor
implementations which implicitly call COMPILE or COMPILE-FILE could bind
*BREAK-ON-WARNINGS* back to NIL if they felt it important to not break
for some reason relating to cultural compatibility. This would not
interfere with the proposed new semantics for the functions COMPILE and
COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when
warnings occur. If the compiler is permitted to warn (separate ballot
item), the effect of this variable on compiler warnings should be nailed
down.
Current Practice:
I would guess that some compilers respect *BREAK-ON-WARNINGS* and others
probably do not.
Adoption Cost:
I assume this is easy to arrange for in all implementations.
Cost of not adopting this change:
Implementations that don't adopt this change will be awkward to use.
Benefits:
This would make the language definition more consistent by making it
less subject to special cases.
Conversion Cost:
Probably little or no user code would be affected by this change.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
KMP supports this change.
Some confusion about differences between compiler warnings and other
kinds of warnings.
Should there be a separate compiler-break-on-warnings?
Is this an environment issue?
∂15-Mar-87 1924 masinter.pa@Xerox.COM Report: meeting of cl-cleanup meeting
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Mar 87 19:24:05 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 87 19:24:49 PST
Date: 15 Mar 87 19:25 PST
From: masinter.pa@Xerox.COM
Subject: Report: meeting of cl-cleanup meeting
To: cl-cleanup@sail.stanford.edu
Message-ID: <870315-192449-2052@Xerox>
Here's the status of the various proposals discussed today:
COMPILER-WARNING-STREAM
Released
DEFVAR-INITIALIZATION
Released
FORMAT-ATSIGN-COLON
Released
IMPORT-SETF-SYMBOL-PACKAGE
Released
PRINC-CHARACTER:WRITE-CHAR
Discussed and agreed, final format not yet available
(write-char choice)
FORMAT-OP-C
Discussed and agreed, final format not yet available
(with Moon's amendment)
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Discussed and agreed, final format not yet available
(choice 1c & 2c)
IGNORE-ERRORS
Discussed and agreed, final format not yet available
IF-BODY
General agreement to recommend against
FLET-IMPLICIT-BLOCK
Do FLET, LABELS add implicit blocks around the bodies?
Tabled, to think about whether removing DEFUN block
would be better because of tail recursion interaction.
COMPILER-WARNING-BREAK
What is a break? How does this interact with condition
proposal, other questions....
Tabled.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
A subset which deals with only those functions that
don't work in positions should be separated out.
FUNCTION-TYPE
Some general agreement to make FUNCTION a type.
Exact details of #'cond generally agreed but some minor
points to work out.
SHARPSIGN-PLUS-MINUS-NUMBER/PACKAGE
No general agreement. Needs further refinement.
SHARPSIGN-BACKSLASH-BITS
No general agreement (the notes read "we cringed")
PEEK-CHAR-READ-CHAR-ECHO
Agreed to be controversial
PROMPT-FOR
Agreed to be controversial
ROB'S-COMPILER-PROPOSAL (provisional title)
Note that the compiler committee is once again active.
ENVIRONMENT-ARGUMENTS (provisional title)
(this includes macro-function-environment, get-setf-method-environment)
∂16-Mar-87 2023 JAR@AI.AI.MIT.EDU Global lexicals
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 16 Mar 87 20:23:08 PST
Date: Mon, 16 Mar 87 23:27:11 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: Global lexicals
To: masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of 15 Mar 87 16:39 PST from masinter.pa at Xerox.COM
Message-ID: <169470.870316.JAR@AI.AI.MIT.EDU>
I'm still working on a proposal for global lexical variables. Turns out
to be a rather sticky question. Sorry I didn't have it ready for y'all
to discuss yesterday, but that's what you get from volunteer labor.
∂17-Mar-87 2015 KVQJ@CSLI.Stanford.EDU please add me
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Mar 87 20:15:14 PST
Date: Tue 17 Mar 87 20:16:50-PST
From: Sheri Markus <KVQJ@CSLI.Stanford.EDU>
Subject: please add me
To: common-lisp@Sail.Stanford.EDU
Message-ID: <12287260322.13.KVQJ@CSLI.Stanford.EDU>
to your mail list.
-------
∂20-Mar-87 1345 VERACSD@A.ISI.EDU Extension to MAP
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 Mar 87 13:24:07 PST
Date: 20 Mar 1987 16:24-EST
Sender: VERACSD@A.ISI.EDU
Subject: Extension to MAP
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd.rs@A.ISI.EDU
Message-ID: <[A.ISI.EDU]20-Mar-87 16:24:21.VERACSD>
I'd really like to see MAP take a sequence as its first
argument, and have the results be put into that sequence.
The first N elements of the sequence would be modified
where N is the min of the lengths of the argument sequences,
(including the sequence passed as the first arg).
This seems upward-compatible and easy to implement, and
would be extremely handy.
Any comments?
Bob Sasseen
veracsd.rs
∂20-Mar-87 1431 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue FLET-IMPLICIT-BLOCK
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Mar 87 14:30:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98373; Fri 20-Mar-87 17:03:26 EST
Date: Fri, 20 Mar 87 17:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue FLET-IMPLICIT-BLOCK
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870315-185544-2035@Xerox>
Message-ID: <870320170250.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I really do not believe that there is any justification based on tail
recursion removal for removing the implicit block from DEFUN. Blocks
that are not referenced do not create any run-time code or data
structure in compiled code in any reasonable implementation, nor in any
unreasonable implementation that I am aware of. They might have some
overhead in the interpreter, but surely tail recursion removal removes
this sort of overhead just as it removes the other sort, and in any
case incompatible semantic changes to the language to micro-optimize
the -interpreter- make no sense.
So I strongly support FLET-IMPLICIT-BLOCK:YES as well as "other
proposal" referenced within it (which I guess does not have a name yet).
∂20-Mar-87 1431 Moon@STONY-BROOK.SCRC.Symbolics.COM Extension to MAP
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Mar 87 14:30:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98379; Fri 20-Mar-87 17:05:49 EST
Date: Fri, 20 Mar 87 17:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Extension to MAP
To: VERACSD@A.ISI.EDU
cc: common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU
In-Reply-To: <[A.ISI.EDU]20-Mar-87 16:24:21.VERACSD>
Message-ID: <870320170530.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 20 Mar 1987 16:24-EST
From: VERACSD@A.ISI.EDU
I'd really like to see MAP take a sequence as its first
argument, and have the results be put into that sequence.
The first N elements of the sequence would be modified
where N is the min of the lengths of the argument sequences,
(including the sequence passed as the first arg).
This seems upward-compatible and easy to implement, and
would be extremely handy.
Any comments?
It sounds like a good idea, but what if the sequence is () ?
∂20-Mar-87 1513 norvig%cogsci.Berkeley.EDU@Berkeley.EDU Re: Extension to MAP
Received: from [128.32.130.5] by SAIL.STANFORD.EDU with TCP; 20 Mar 87 15:13:33 PST
Received: by cogsci.berkeley.edu (5.57/1.23)
id AA11109; Fri, 20 Mar 87 15:14:07 PST
Date: Fri, 20 Mar 87 15:14:07 PST
From: norvig%cogsci.Berkeley.EDU@berkeley.edu (Peter Norvig)
Message-Id: <8703202314.AA11109@cogsci.berkeley.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: Extension to MAP
Cc: moon@stony-brook.scrc.symbolics.com
Date: 20 Mar 1987 16:24-EST
From: VERACSD@A.ISI.EDU
I'd really like to see MAP take a sequence as its first
argument, and have the results be put into that sequence.
Seems to me the answer is smarter compilers. Then the code could read:
(replace seq1 (map (type-of seq1) fnc seq2))
and compile into the same thing as the proposed (map seq1 fnc seq2).
Similarly, one could have
(mapc f (mapcar g l1)) ==> (mapc #'(lambda (x) (funcall f (funcall g x))) l1)
where the "==>" stands for "optimizes into". People expect such optimizations
from APL or SetL compilers; why not from CommonLisp? I admit there are
complications involving side effects and error signaling. For example,
(first (mapcar #'not l)) ==> (not (first l))
but
(first (mapcar #'print l)) ==> (unless (null l)
(print (first l))
(mapc #'print (rest l)))
and
(dotimes (i 10000) (cons nil nil)) ==> nil
would be valid most of the time, but not when you're trying to test
the garbage collector.
∂20-Mar-87 1805 FAHLMAN@C.CS.CMU.EDU Issue FLET-IMPLICIT-BLOCK
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Mar 87 18:05:20 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 20 Mar 87 21:05:56-EST
Date: Fri, 20 Mar 1987 21:05 EST
Message-ID: <FAHLMAN.12288022897.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue FLET-IMPLICIT-BLOCK
I don't think I'm willing to go for any combination of proposals that
requires both tail-recursion removal in the interpreter and implicit
blocks around the tail-recursive forms in question. I grant that a
"sufficiently smart" interpreter might be able to fight its way through
this somehow, perhaps by doing a pre-pass over each form to see if any
blocks are actually referenced or by consing continuations in the heap,
but I don't want to get into this kind of added hair.
Of course, if the requirement for tail-recursion removal were to apply
only to compiled code, then there is no conflict with implicit blocks:
if unused the block is never created; if the block used, the form is not
tail-optimizable (or maybe special code can be generated to smash the
block when the tail-recursive call occurs).
So I'd like to hear from Guy just what he wants to propose in the way of
tail-recursion removal. Would it be required in the interpreter or only
in the compiler? Required only of LABELS, or of DEFUNs as well? Any
such requirement is going to be hard to sell, so we should probably not
let the dim future prospect of such things tie up other proposed
improvements unless someone wants to come forward with a proposal now.
-- Scott
∂20-Mar-87 2130 Moon@STONY-BROOK.SCRC.Symbolics.COM Issue FLET-IMPLICIT-BLOCK
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Mar 87 21:30:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98586; Sat 21-Mar-87 00:29:49 EST
Date: Sat, 21 Mar 87 00:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue FLET-IMPLICIT-BLOCK
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12288022897.BABYL@C.CS.CMU.EDU>
Message-ID: <870321002931.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 20 Mar 1987 21:05 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
I don't think I'm willing to go for any combination of proposals that
requires both tail-recursion removal in the interpreter and implicit
blocks around the tail-recursive forms in question. I grant that a
"sufficiently smart" interpreter might be able to fight its way through
this somehow, perhaps by doing a pre-pass over each form to see if any
blocks are actually referenced or by consing continuations in the heap,
but I don't want to get into this kind of added hair.
Scott, I think you missed the point of my comment. Let me try saying it
a different way. Because it has dynamic extent, the block around a
function has the same lifetime as the return address (aka continuation)
of that function. An interpreter that can forget one when it makes a
tail recursive call can forget the other. Now, you may be worried about
the fact that making a tail recursive call does not exit the lexical
scope of the block, because it might have been captured by a closure of
an internal function. The easy answer is that tail-recursive iterations
don't do this, because if they did they would cons closures, so all you
need is a bit in a lexical contour to indicate whether it has ever been
captured in a closure. Since you don't want to get into added hair, I
won't go into any more complex answers. They exist; you can even find
one in a Le Lisp paper!
So I'd like to hear from Guy just what he wants to propose in the way of
tail-recursion removal.
So would I. My guess at a reason for the delay is that anyone who tries
to define "tail recursion removal" in a way that is precise, machine
independent, and implementation independent discovers it to be
impossible. It would be interesting to be proved wrong.
∂21-Mar-87 0147 RWK@YUKON.SCRC.Symbolics.COM Extension to MAP
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 21 Mar 87 01:47:01 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182092; Sat 21-Mar-87 04:47:04 EST
Date: Sat, 21 Mar 87 04:47 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Extension to MAP
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU,
veracsd.rs@A.ISI.EDU
In-Reply-To: <870320170530.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870321044705.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Fri, 20 Mar 87 17:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: 20 Mar 1987 16:24-EST
From: VERACSD@A.ISI.EDU
I'd really like to see MAP take a sequence as its first
argument, and have the results be put into that sequence.
The first N elements of the sequence would be modified
where N is the min of the lengths of the argument sequences,
(including the sequence passed as the first arg).
This seems upward-compatible and easy to implement, and
would be extremely handy.
Any comments?
It sounds like a good idea, but what if the sequence is () ?
I'm not sure which objection you're making, so I'll clarify by
generalizing it twice.
1) Generalize this to "What if the sequence is shorter than the
number of times the mapped function would otherwise be called?"
2) Generalize this to "What if the sequence is (array t)?"
The first interpretation is a trivial design decision, but the second is
a fatal flaw in the scheme. I suspect this is really the point you were
trying to make: some sequences already have meaning in that context.
∂21-Mar-87 1248 barmar@Think.COM Extension to MAP
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 21 Mar 87 12:41:37 PST
Received: from sebastian by Think.COM via CHAOS; Sat, 21 Mar 87 15:41:50 EST
Date: Sat, 21 Mar 87 15:42 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Extension to MAP
To: VERACSD@a.isi.edu
Cc: common-lisp@sail.stanford.edu, veracsd.rs@a.isi.edu
In-Reply-To: <[A.ISI.EDU]20-Mar-87 16:24:21.VERACSD>
Message-Id: <870321154234.3.BARMAR@SEBASTIAN.THINK.COM>
Date: 20 Mar 1987 16:24-EST
From: VERACSD@a.isi.edu
I'd really like to see MAP take a sequence as its first
argument, and have the results be put into that sequence.
Unfortunately, MAP already has a defined meaning when its first argument
is a sequence, because a list is a sequence and there are type
specifiers that are lists.
barmar
∂21-Mar-87 1555 vrotney@venera.isi.edu Re: Extension to MAP
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 Mar 87 15:55:53 PST
Posted-Date: Sat, 21 Mar 87 15:56:37 PDT
Received: from hpai00.isi.edu by venera.isi.edu (5.54/5.51)
id AA07882; Sat, 21 Mar 87 15:56:39 PST
Received: by hpai00 ; Sat, 21 Mar 87 15:56:47 pst
From: vrotney@venera.isi.edu
Message-Id: <8703212356.AA04228@hpai00>
Date: Sat, 21 Mar 87 15:56:37 PDT
Subject: Re: Extension to MAP
To: common-lisp@sail.stanford.edu
In-Reply-To: Your message of 20-Mar-87 16:24:00
X-Mailer: NMail [$Revision: 2.6 $]
re:
--------------------------------------------------------------------------------
Subject: Extension to MAP
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: veracsd.rs@A.ISI.EDU
Message-Id: <[A.ISI.EDU]20-Mar-87 16:24:21.VERACSD>
I'd really like to see MAP take a sequence as its first
argument, and have the results be put into that sequence.
--------------------------------------------------------------------------------
This sounds like a good idea but your syntax might have problems. For
example , a type specifier that is a subtype of type sequence might be
(I can't show this) a list (CLTT p42) which is itself a sequence.
One way to implement your idea would be to extend CLTL as follows:
CLTL states that the first argument to MAP must be NIL or a subtype of
sequence. Propose we extend so that if the first argument is anything
else then the result type is of the type of the first sequence. In
particular,
(map t function seq1 ...) => <sequence of type seq1>
would give you your desired effect.
Bill Vrotney USC/ISI
-------
∂21-Mar-87 2117 kempf%hplabsc@hplabs.HP.COM CommonObjects on CommonLoops
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 21 Mar 87 21:17:36 PST
Received: from hplabsc by hplabs.HP.COM with TCP ; Sat, 21 Mar 87 21:17:27 pst
Received: by hplabsc ; Sat, 21 Mar 87 21:19:15 pst
Date: Sat, 21 Mar 87 21:19:15 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8703220519.AA24502@hplabsc>
To: common-lisp@sail.stanford.edu, commonloops.pa@xerox.com
Subject: CommonObjects on CommonLoops
******* Announcing CommonObjects on CommonLoops *******
A portable implementation of HP's CommonObjects
object-oriented programming language is now available.
More information on CommonObjects semantics can be found
in the article "CommonObjects: An Overview" by Alan
Snyder in the October, 1986 issue of SIGPLAN Notices,
or by mailing a request for the technical report
ATC-85-1 to mingus@hplabs.hp.com
CommonObjects on CommonLoops (COOL) uses the metaclass
kernel of Portable CommonLoops (PCL) to implement
95% of CommonObjects functionality. Both COOL
and PCL run embedded in Common Lisp. COOL is
freely distributable and available via anonymous FTP from
ingres.berkeley.edu. It is located in the directory
/ja/guest/kempf/public/cool.
Tests of COOL in HP Common Lisp (where it was developed)
and Kyoto Common Lisp have been made, and it is
designed to be as portable as PCL. Currently, COOL
runs on the 2/24/87 release of PCL. In order to
avoid software tracking problems, the release of
PCL in which COOL runs will be distributed along
with COOL. In the cool directory are two subdirectories,
one containing the PCL source (pcl) and one containing
the COOL source (cool). The (upper) cool directory also contains
a README file describing how to build and use the system.
The cool/cool directory, in addition to the COOL source, contains
a series of regression tests and profiling tests.
Please report any problems with COOL to cool@hplabs.hp.com.
We are interested in any portability problems but cannot
attempt to fix them unless we can either get access to a
running system where the problem is occuring or get enough
information that we can help a knowledgable Common Lisp
programmer fix the problem.
∂22-Mar-87 0954 FAHLMAN@C.CS.CMU.EDU Issue FLET-IMPLICIT-BLOCK
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Mar 87 09:53:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 22 Mar 87 12:17:39-EST
Date: Sun, 22 Mar 1987 09:52 EST
Message-ID: <FAHLMAN.12288424680.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue FLET-IMPLICIT-BLOCK
In-reply-to: Msg of 21 Mar 1987 00:29-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
Scott, I think you missed the point of my comment. Let me try saying it
a different way. Because it has dynamic extent, the block around a
function has the same lifetime as the return address (aka continuation)
of that function. An interpreter that can forget one when it makes a
tail recursive call can forget the other.
I guess you're right in saying that the existence of the implicit block
doesn't add too much additional complexity to any interpreter that would
eliminate tail recursion. I guess my real position is that I am pretty
unlikely to swallow any proposal to require such tail-recursion removal,
with or without the implicit blocks. I'm not fond of "interpreters"
that do partial compilation -- the whole point of having an interpreter
is to allow debugging of code that is close to what the user wrote --
and I'm even more skeptical of any plan that requires internal consing
of continuations merely in order to avoid growing the stack by
recursion.
So I agree with you that considerations of future tail-recursion
proposals should probably not influence our consideration of this block
business, though we seem to reach this conclusion by different paths:
you think it is easy enough in either case, while I think it is too hard
in either case.
There remains the issue of whether the implicit blocks makes
code-maintenance harder by putting references to the function name
within the body of the function object, when these two things ought to
be unconnected. But we debated that before and decided to put the
implicit blocks into Defun. We might not make the same decision today,
but I don't think that we've seen anything new that would warrant an
incompatible change to Defun at this point. And if we keep the block
around Defun, we probably should go for consistency by adding the blocks
in the other places that have been proposed.
-- Scott
∂22-Mar-87 0954 rda%epistemi.edinburgh.ac.uk@Cs.Ucl.AC.UK Request to be added to mailing list
Received: from TUNNEL.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 22 Mar 87 09:54:06 PST
Received: from epistemi.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK
via Janet with NIFTP id aa03737; 22 Mar 87 13:46 WET
From: Robert Dale <rda%epistemi.edinburgh.ac.uk@Cs.Ucl.AC.UK>
Date: Sun, 22 Mar 87 13:45:15 gmt
Message-Id: <19382.8703221345@epistemi.ed.ac.uk>
To: COMMON-LISP <@Cs.Ucl.AC.UK:COMMON-LISP@sail.stanford.edu>
Subject: Request to be added to mailing list
Please add me to your mailing list.
Thanks
Robert Dale University of Edinburgh, Centre for Cognitive Science,
2 Buccleuch Place, Edinburgh, EH8 9LW, Scotland.
UUCP: ...!ukc!cstvax!epistemi!rda
ARPA: rda%epistemi.ed.ac.uk@ucl.cs
JANET: rda@uk.ac.ed.epistemi
∂22-Mar-87 2009 kempf%hplabsc@hplabs.HP.COM Re: CommonObjects on CommonLoops
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Mar 87 20:09:13 PST
Received: from hplabsc by hplabs.HP.COM with TCP ; Sun, 22 Mar 87 20:08:55 pst
Received: by hplabsc ; Sun, 22 Mar 87 20:10:16 pst
Date: Sun, 22 Mar 87 20:10:16 pst
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8703230410.AA13557@hplabsc>
To: common-lisp@sail.stanford.edu, commonloops.pa@xerox.com
Subject: Re: CommonObjects on CommonLoops
As several people have noticed, it is not possible to get to
/ja/guest/kempf/public via anonymous ftp. I have set up the
COOL distribution so that it is in /pub/cool, rather than
/ja/guest/kempf/public. If anybody has taken the cool.tar
file which was in /pub, it contains the cool distribution
in U*NX tar format, but it was not properly made so there
may be trouble un-taring it. In any event, I would suggest if
you have trouble, that you simply get the new distribution.
Again, there are two subdirectories under /pub/cool-cool and
pcl, containing, respectively, the COOL release and the 2/24/87
PCL release. The directory /pub/cool itself contains a README
file.
Thanks for your patience and I'm sorry for the confusion. Let
us know how you're doing.
Jim Kempf cool@hplabs.hp.com
∂23-Mar-87 0949 Masinter.pa@Xerox.COM Re: Issue FLET-IMPLICIT-BLOCK
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Mar 87 09:49:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 87 09:49:33 PST
Date: 23 Mar 87 09:52 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue FLET-IMPLICIT-BLOCK
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun,
22 Mar 87 09:52 EST
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870323-094933-9728@Xerox>
Am I correct that there are no more objections to FLET-IMPLICIT-BLOCK?
If not, can someone volunteer to summarize the discussion about tail
recursion costs and put it in a revised version of the proposal?
Thanks,
Larry
∂23-Mar-87 1005 HASSETT%sp.unisys.com@RELAY.CS.NET Extension to MAP
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Mar 87 10:05:31 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa13137; 23 Mar 87 12:51 EST
Received: from sp.unisys.com by RELAY.CS.NET id aa11418; 23 Mar 87 12:47 EST
Date: Mon, 23 Mar 87 08:47 CST
From: Jim Hassett <HASSETT%sp.unisys.com@RELAY.CS.NET>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Extension to MAP
X-VMS-To: IN%"common-lisp@sail.stanford.edu"
Date: Sat, 21 Mar 87 15:42 EST
From: Barry Margolin <barmar@think.com>
Date: 20 Mar 1987 16:24-EST
From: VERACSD@a.isi.edu
I'd really like to see MAP take a sequence as its first
argument, and have the results be put into that sequence.
Unfortunately, MAP already has a defined meaning when its first argument
is a sequence, because a list is a sequence and there are type
specifiers that are lists.
Right. We can't allow another interpretation for something that might be a
type specifier.
From: vrotney@venera.isi.edu
Date: Sat, 21 Mar 87 15:56:37 PDT
CLTL states that the first argument to MAP must be NIL or a subtype of
sequence. Propose we extend so that if the first argument is anything
else then the result type is of the type of the first sequence. In
particular,
(map t function seq1 ...) => <sequence of type seq1>
would give you your desired effect.
One problem here is that T is a type specifier (though it does not specify
a subtype of SEQUENCE). A more serious problem is that it doesn't do what
was originally desired: modify an existing sequence (or is it proposed to
modify SEQ1?). Also, SEQ1 might not happen to be of the desired result type.
One possible upward-compatible extension would be to allow the first argument
to be a list of the form (onto <sequence>). There is no ambiguity since this
is not a type specifier. In actual use, the backquote would be the most
convenient means of constructing such a list:
(map `(onto ,my-result-sequence) function seq1 ...)
Jim Hassett
∂23-Mar-87 1145 VERACSD@A.ISI.EDU Replies to Extension to MAP
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Mar 87 11:45:49 PST
Date: 23 Mar 1987 14:45-EST
Sender: VERACSD@A.ISI.EDU
Subject: Replies to Extension to MAP
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: moon@SCRC-STONY-BROOK.ARPA
Cc: rwk@SCRC-YUKON.ARPA
Cc: barmar@THINK.COM
Cc: vrotney@VENERA.ISI.EDU
Cc: veracsd@A.ISI.EDU
Cc: norvig%cogsci.berkeley.edu@UCBVAX.BERKELEY.EDU
Message-ID: <[A.ISI.EDU]23-Mar-87 14:45:49.VERACSD>
Thanks for the replies to my suggestion that MAP be extended to
take a first arg of a sequence which would be FILLed with the results
of the MAPping.
Moon is right that a first arg of () would be ambiguous since it
could be interpreted either as a zero-length sequence, or NIL specifying
to do the mapping but return no results.
Kerns and Margolin are right that a first arg such as (ARRAY T)
would also be ambiguous because it could be interpreted either as a
sequence to be filled or as a type specifier for a new sequence.
Kerns seems to be right that these are fatal flaws, the essential
problem being that some sequences already have meaning as the first arg
MAP. The feature would be nice to have but at the moment I can't see
any way to overcome this problem (which I really shouldn't have had to
have pointed out to me).
Vrotney misinterpreted what I was intending the extension to accomplish.
What he suggests can be achieved without much extra trouble by saying
(MAP (TYPE-OF seq) FN ... ), especially if TYPE-OF is as specific as
possible.
Bob Sasseen
∂23-Mar-87 2111 Pavel.pa@Xerox.COM (THE (VALUES ...) ...) with &KEY
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Mar 87 21:11:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 87 21:11:57 PST
Date: 23 Mar 87 21:11 PST
From: Pavel.pa@Xerox.COM
Subject: (THE (VALUES ...) ...) with &KEY
To: Common-Lisp@Sail.Stanford.Edu
Message-ID: <870323-211157-1162@Xerox>
CLtL, on page 48, says, in reference to the VALUES type specifier,
``The &OPTIONAL, &REST, and &KEY markers may appear in the value-type
list; they thereby indicate the parameter list of a function that, when
given to MULTIPLE-VALUE-CALL along with the values, would be suitable to
receiving those values.''
I assume from this that the following form is legal and specifies that
it is an error for FOO to return less than 3 values, the first of which
should be an integer and the second of which should be a float:
(the (values integer &optional float &rest cons) (foo))
The insistence on three or more values comes from the requirement that
the &REST list be of type CONS; if fewer values were returned, it would
be NIL, not a cons-cell. Thus, the &optional in this case is
superfluous.
I would also guess that this next form requires BAR to return either one
or two values, the first of which must be a string and the second of
which, if provided, must be an array:
(the (values string &optional array) (bar))
I am at a loss, however, to figure out how to use the &KEY keyword.
What is the right syntax for invoking this arcane feature? Perhaps each
keyword ``parameter'' should be a list of two elements, a symbol naming
the appropriate keyword and the type the corresponding value should
have? This seems reasonable (at least relative to the whole notion
being reasonable), but none of the implementations I've tried understand
any of the lambda-list keywords, let alone &KEY...
Does anyone implement this? Does anyone (shudder) use it? Could we
just eliminate it from the language? Cleanup committee, are you
listening?
Pavel
∂24-Mar-87 1437 RAM@C.CS.CMU.EDU (THE (VALUES ...) ...) with &KEY
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Mar 87 14:37:37 PST
Received: ID <RAM@C.CS.CMU.EDU>; Tue 24 Mar 87 17:38:15-EST
Date: Tue, 24 Mar 1987 17:38 EST
Message-ID: <RAM.12289033676.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Pavel.pa@XEROX.COM
Cc: Common-Lisp@SAIL.STANFORD.EDU
Subject: (THE (VALUES ...) ...) with &KEY
In-reply-to: Msg of 24 Mar 1987 00:11-EST from Pavel.pa at Xerox.COM
In the context of FUNCTION types, these issues are discussed in the
cleanup list circulated by Guy way back when. He proposed that
keyword arguments be represented by a 2list of the keyword and the
type, and that the type specified for a rest arg would be the type of
the additional arguments rather than of the rest arg itself.
It is an open question whether we really want all this hair in the
VALUES type spec, but CLTL currently seems suggest that it is the same
as the FUNCTION type spec.
Rob
∂25-Mar-87 1256 gls@Think.COM Issue FLET-IMPLICIT-BLOCK
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Mar 87 12:56:21 PST
Received: from falling-star by Think.COM via CHAOS; Wed, 25 Mar 87 15:54:37 EST
Date: Wed, 25 Mar 87 15:55 EST
From: Guy Steele <gls@Think.COM>
Subject: Issue FLET-IMPLICIT-BLOCK
To: Fahlman@c.cs.cmu.edu, Moon@scrc-stony-brook.arpa
Cc: cl-cleanup@sail.stanford.edu, gls@think.com
In-Reply-To: <FAHLMAN.12288424680.BABYL@C.CS.CMU.EDU>
Message-Id: <870325155511.9.GLS@FALLING-STAR.THINK.COM>
Date: Sun, 22 Mar 1987 09:52 EST
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Scott, I think you missed the point of my comment. Let me try saying it
a different way. Because it has dynamic extent, the block around a
function has the same lifetime as the return address (aka continuation)
of that function. An interpreter that can forget one when it makes a
tail recursive call can forget the other.
I guess you're right in saying that the existence of the implicit block
doesn't add too much additional complexity to any interpreter that would
eliminate tail recursion. I guess my real position is that I am pretty
unlikely to swallow any proposal to require such tail-recursion removal,
with or without the implicit blocks. I'm not fond of "interpreters"
that do partial compilation -- the whole point of having an interpreter
is to allow debugging of code that is close to what the user wrote --
and I'm even more skeptical of any plan that requires internal consing
of continuations merely in order to avoid growing the stack by
recursion. ...
I believe that if I seriously intend to propose tail-recursion removal it is
incumbent upon me to include as part of that proposal a disucssion of how to
implement an interpreter so that tail-recursion works for blocks, whether
explicit or implicit, without consing of continuations. (I reserve the right,
however, to generate distinct pointers, each having dynamic extent, for use as
catch tags, by the strategem of using pointers into the stack, say to the very
catch frame itself.)
--Guy
∂25-Mar-87 1321 gls@Think.COM Replies to Extension to MAP
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Mar 87 13:21:06 PST
Received: from falling-star by Think.COM via CHAOS; Wed, 25 Mar 87 16:20:23 EST
Date: Wed, 25 Mar 87 16:20 EST
From: Guy Steele <gls@Think.COM>
Subject: Replies to Extension to MAP
To: VERACSD@a.isi.edu, common-lisp@sail.stanford.edu
Cc: moon@scrc-stony-brook.arpa, rwk@scrc-yukon.arpa, barmar@think.com,
vrotney@venera.isi.edu, norvig%cogsci.berkeley.edu@ucbvax.berkeley.edu,
gls@think.com
In-Reply-To: <[A.ISI.EDU]23-Mar-87 14:45:49.VERACSD>
Message-Id: <870325162049.3.GLS@FALLING-STAR.THINK.COM>
I really shouldn't, but I will...
How about, if the first arg to MAP is an integer, it specifies
which argument should be clobbered? This doesn't allow an
unrelated sequence to be be clobbered, of course, but it does
allow the common case of an in-place MAP operation.
(MAP 1 FN SEQ1 SEQ2) ;clobbers SEQ1 with answers
(MAP 2 FN SEQ1 SEQ2) ;clobbers SEQ2 with answers
--Quux
∂25-Mar-87 1426 samalone@ATHENA.MIT.EDU Extension to MAP
Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 14:26:30 PST
Received: by ATHENA (5.45/4.7)
id AA19099; Wed, 25 Mar 87 17:14:54 EST
From: <samalone@ATHENA.MIT.EDU>
Received: by HADES (5.45/4.7)
id AA20554; Wed, 25 Mar 87 17:13:33 EST
Message-Id: <8703252213.AA20554@HADES>
To: common-lisp@sail.stanford.edu
Subject: Extension to MAP
Date: Wed, 25 Mar 87 17:13:32 EST
Why not just define a new function, NMAP, which takes as its first argument a
sequence to be modified instead of a type specifier? Or am I spoiling your
fun?
--SAM
∂25-Mar-87 1458 edsel!bhopal!jonl@navajo.stanford.edu Numerical Comparison: "required coercions"
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 14:57:23 PST
Received: by navajo.stanford.edu; Wed, 25 Mar 87 14:55:24 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA16972; Wed, 25 Mar 87 14:55:53 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA09954; Wed, 25 Mar 87 14:52:35 PST
Date: Wed, 25 Mar 87 14:52:35 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8703252252.AA09954@bhopal.edsel.com>
To: navajo!Common-Lisp%su-ai@navajo.stanford.edu
Subject: Numerical Comparison: "required coercions"
Section 12.3 of CLtL, when speaking of the numerical comparison
functions -- =, /=, <, etc. -- says that each one works on all types
of numbers (unless otherwise indicated), and that any "required
coercions" are performed when the arguments are of different type.
Which kind of coercion is appropriate for the following:
(= 314159265358979383256 ;about 20 digits of pi, as integer
3.1415925E20 ; pi * 1.0E20, off by one lsb maybe
314159265358979383250 ;a different "20 digits" of pi
)
??
Some implementations I've looked at appear to do the coercion by the
usual rule of float-contagion. I believe this to be sub-optimal in
that it prevents "=" from being a transitive operation (because
floating the two integers above will typically "lose" information).
Wouldn't it make more sense to consider the phrase "required coercions"
to mean that when a rational is compared to a float, it is the float
that is "coerced" rather than the rational?
In short, I don't think the original intent was that "=" be a "fuzzy"
operation. Rather it should be mathematically consistent, even if the
interpretation of "precision" for floating-point numbers is open to
question.
-- JonL --
∂25-Mar-87 1702 FAHLMAN@C.CS.CMU.EDU Replies to Extension to MAP
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 17:02:29 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 25 Mar 87 20:03:13-EST
Date: Wed, 25 Mar 1987 20:03 EST
Message-ID: <FAHLMAN.12289322220.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: Guy Steele <gls@THINK.COM>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Replies to Extension to MAP
In-reply-to: Msg of 25 Mar 1987 16:20-EST from Guy Steele <gls at Think.COM>
How about, if the first arg to MAP is an integer, it specifies
which argument should be clobbered? This doesn't allow an
unrelated sequence to be be clobbered, of course, but it does
allow the common case of an in-place MAP operation.
This is a joke, right?
If people really want a form that works like MAP but is destructive of
one of the sequences, it is trivial to define a macro to do the job.
If people really think that this is so useful that we need to add it to
Common Lisp, the right way to do this is to define some new function,
with a new name, that does this job.
The idea of extending MAP in a compatible way was cute, but dangerous:
it is usually a mistake to overload the same function to do two
fundamentally different things depending on some subtle type
distinction. If you want a destructive operation, you should ask for it
by name. Then if a sequence gets clobbered mysteriously, you have some
hope of finding the code responsible.
Since the original MAP proposal turned out to be unworkable, I think it
is best to let it die rather than trying think up even more subtle ways
to sneak this behavior into MAP.
-- Scott
∂25-Mar-87 1931 fateman@mike.berkeley.edu Re: Numerical Comparison: "required coercions"
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 19:31:21 PST
Received: from UCBVAX.Berkeley.EDU by navajo.stanford.edu with TCP; Wed, 25 Mar 87 19:29:28 PST
Received: by ucbvax.Berkeley.EDU (5.57/1.23)
id AA06689; Wed, 25 Mar 87 17:35:13 PST
Received: by mike (3.2/5.17)
id AA05122; Wed, 25 Mar 87 17:34:29 PST
Date: Wed, 25 Mar 87 17:34:29 PST
From: fateman@mike.berkeley.edu (Richard Fateman)
Message-Id: <8703260134.AA05122@mike>
To: edsel!bhopal!jonl@navajo.stanford.edu,
navajo!Common-Lisp%su-ai@navajo.stanford.edu
Subject: Re: Numerical Comparison: "required coercions"
yep.
∂25-Mar-87 1937 VERACSD@A.ISI.EDU More on MAP
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 19:37:28 PST
Date: 25 Mar 1987 22:37-EST
Sender: VERACSD@A.ISI.EDU
Subject: More on MAP
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: fahlman@C.CS.CMU.EDU, veracsd.rs@A.ISI.EDU
Message-ID: <[A.ISI.EDU]25-Mar-87 22:37:15.VERACSD>
Apropos Scott Fahlman's remarks:
1) I trust Guy Steele was indeed joking in proposing that
> if the first arg to MAP is an integer, it specifies which argument
> should be clobbered
2)
> If you want a destructive operation, you should ask for it by name.
This is reasonable enough. "Samalone", in fact, proposes NMAP.
3) But
> it is usually a mistake to overload the same function to do two
> fundamentally different things depending on some subtle type
> distinction
I buy this in general, but wonder about its application to this case,
since a) how fundamentally different or subtle is it really, b) MAP
already does two different things, when given NIL and when given a
(non-NIL) type specifier, and c) it's basically the overloading of NIL
and certain other (type-specifying) sequences that caused the original
proposal to fail.
4) Perhaps I am putting my foot in my mouth (again), but I question
whether
> it is trivial to define a macro to do the job
of the proposed extension. I imagine Fahlman is thinking of something
like '(replace ,seq (map (type-of ,seq) ,fn ,@sequences), but the
point of the extension was to have a function which accomplishes this
without the extra time and space of consing and the time of replacing.
5) How about NMAP, anyway?
Bob Sasseen
veracsd.rs@a.isi.edu
∂25-Mar-87 2030 FAHLMAN@C.CS.CMU.EDU More on MAP
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 20:29:51 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 25 Mar 87 23:30:05-EST
Date: Wed, 25 Mar 1987 23:30 EST
Message-ID: <FAHLMAN.12289359878.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: VERACSD@A.ISI.EDU
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: More on MAP
In-reply-to: Msg of 25 Mar 1987 22:37-EST from VERACSD at A.ISI.EDU
4) Perhaps I am putting my foot in my mouth (again), but I question
whether
> it is trivial to define a macro to do the job
of the proposed extension. I imagine Fahlman is thinking of something
like '(replace ,seq (map (type-of ,seq) ,fn ,@sequences), but the
point of the extension was to have a function which accomplishes this
without the extra time and space of consing and the time of replacing.
No, I was imagining a macro that would expand into a do-loop that
wouldn't cons. It could use ELT and SETF of ELT if you want it to apply
to all kinds of sequences.
Why don't you write what you think is the right thing -- NMAP or
whatever -- in portable Common Lisp, pass the code out, and see if it
becomes popular enough that we should consider adding it to the base
language.
-- Scott
∂25-Mar-87 2101 STEVER%OZ.AI.MIT.EDU@AI.AI.MIT.EDU Free variables in a LAMBDA which names a function
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 21:01:39 PST
Date: Thu 26 Mar 87 00:01-EST
From: "Stephen E. Robbins" <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Free variables in a LAMBDA which names a function
To: common-lisp@SAIL.STANFORD.EDU
Section 5.2 of CLtL point out that there's a distinction between
(LAMBDA ...) as a way of \naming/ a function, and as a function
object.
What are the semantics of a free variable within a LAMBDA which
merely \names/ a function? For example:
(defun foo (arg)
((lambda (x) (+ x arg)) 5))
I would expect:
(setf arg 16)
(foo 3) ==> 8
I'm using a beta test of a Common Lisp which returns 21 as the
result of that (foo 3). Looking through CLtL, I see nothing that
implies that (lambda ...) in the functional position of a form
has its free variables interpreted lexically, rather than dynamically.
Am I overlooking something? Is it reasonable to expect (foo 3) to
return 8, or am I depending on coincidence...
[This question arose when trying out the Common Lisp version of
LOOP which GSB passed on to me a few weeks back. That LOOP
expands into expressions which require that free variables in
initial lambdas be lexically scoped]
- Steve
∂25-Mar-87 2124 BROOKS%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Free variables in a LAMBDA which names a function
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Mar 87 21:24:18 PST
Date: Thu, 26 Mar 1987 00:24 EST
Message-ID: <BROOKS.12289369766.BABYL@MIT-OZ>
From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: "Stephen E. Robbins" <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Free variables in a LAMBDA which names a function
In-reply-to: Msg of 26 Mar 1987 00:01-EST from Stephen E. Robbins <STEVER>
(defun foo (arg)
((lambda (x) (+ x arg)) 5))
I would expect:
(setf arg 16)
(foo 3) ==> 8
That is correct. `arg' is lexically scoped. Except for declaration handling
you can treat an expression with a lambda, of a fixed number of arguments,
in the functional position as if it were the obvious expansion of a let
expression (or vice versa). Declarations (especially special declarations)
screw up this simple model however.
∂25-Mar-87 2143 barmar@Think.COM Free variables in a LAMBDA which names a function
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Mar 87 21:43:39 PST
Received: from ubaldo by Think.COM via CHAOS; Thu, 26 Mar 87 00:43:39 EST
Date: Thu, 26 Mar 87 00:44 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Free variables in a LAMBDA which names a function
To: Stephen E. Robbins <STEVER%OZ.AI.MIT.EDU@xx.lcs.mit.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8703260503.AA02722@Think.COM>
Message-Id: <870326004412.0.BARMAR@UBALDO.THINK.COM>
Date: Thu 26 Mar 87 00:01-EST
From: "Stephen E. Robbins" <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Section 5.2 of CLtL point out that there's a distinction between
(LAMBDA ...) as a way of \naming/ a function, and as a function
object.
What are the semantics of a free variable within a LAMBDA which
merely \names/ a function? For example:
(defun foo (arg)
((lambda (x) (+ x arg)) 5))
I would expect:
(setf arg 16)
(foo 3) ==> 8
I'm using a beta test of a Common Lisp which returns 21 as the
result of that (foo 3). Looking through CLtL, I see nothing that
implies that (lambda ...) in the functional position of a form
has its free variables interpreted lexically, rather than dynamically.
8 is the correct result. Function parameters have lexical scope, so the
scope of the "arg" parameter is the entire body of the function. There
is nothing in CLtL that says that lexical scope "skips over" embedded
lambda expressions. My guess is that the compiler you are testing
translated the definition into:
(defun foo (arg)
(#:gensym 5))
(defun #:gensym (x)
(+ x arg))
This would be OK in a dynamically-scoped Lisp (in fact, I believe the
Maclisp compiler did exactly this), but not in Common Lisp. Your
definition should be equivalent to
(defun foo (arg)
(flet ((#:gensyn (x) (+ x arg)))
(#:gensym 5)))
You should also get the result 8 in a dynamically-scoped Lisp, or in
Common Lisp if arg is proclaimed special.
barmar
∂25-Mar-87 2201 Moon@STONY-BROOK.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Mar 87 22:01:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 101668; Thu 26-Mar-87 00:59:44 EST
Date: Thu, 26 Mar 87 00:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Numerical Comparison: "required coercions"
To: Common-Lisp@sail.stanford.edu
cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8703252252.AA09954@bhopal.edsel.com>
Message-ID: <870326005921.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 25 Mar 87 14:52:35 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Section 12.3 of CLtL, when speaking of the numerical comparison
functions -- =, /=, <, etc. -- says that each one works on all types
of numbers (unless otherwise indicated), and that any "required
coercions" are performed when the arguments are of different type.
This part of the book is particularly unclear, but since pages 196 and
199 both use the same "required coercions" phrase I think they must both
be referring to the coercions described in section 12.1.
....
Wouldn't it make more sense to consider the phrase "required coercions"
to mean that when a rational is compared to a float, it is the float
that is "coerced" rather than the rational?
Offhand it seems like it would make more sense. I would certainly feel
better if Common Lisp's = and EQUALP functions were transitive. But I
think CLtL as currently written could only be saying that the rule of
floating-point contagion is to be followed, the opposite of your
suggestion.
In short, I don't think the original intent was that "=" be a "fuzzy"
operation. Rather it should be mathematically consistent, even if the
interpretation of "precision" for floating-point numbers is open to
question.
Well, it's pretty clear that the original intent wasn't as fully
thought-out as we would like!
Do you propose that = of two floating-point numbers of different
precision use the longer of the two precisions (which appears to be what
CLtL prescribes), or use the shorter of the two precisions (which would
cause fewer surprises to people who don't really understand what
floating-point is and is not)?
May I suggest writing this proposal up more formally and running it
through the X3J13 cleanup subcommittee? That seems like a good way to
ensure that all the ramifications get considered.
The IEEE floating-point standard may speak to mixed-mode and
mixed-precision comparisons; I don't know about that, but if it does,
Common Lisp ought to follow it.
∂26-Mar-87 0259 RWK@YUKON.SCRC.Symbolics.COM Free variables in a LAMBDA which names a function
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Mar 87 02:59:41 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 184419; Thu 26-Mar-87 05:56:59 EST
Date: Thu, 26 Mar 87 05:56 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Free variables in a LAMBDA which names a function
To: Barry Margolin <barmar@Think.COM>
cc: Stephen E. Robbins <STEVER%OZ.AI.MIT.EDU@xx.lcs.mit.edu>,
common-lisp@sail.stanford.edu
In-Reply-To: <870326004412.0.BARMAR@UBALDO.THINK.COM>
Message-ID: <870326055657.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 26 Mar 87 00:44 EST
From: Barry Margolin <barmar@Think.COM>
My guess is that the compiler you are testing
translated the definition into:
(defun foo (arg)
(#:gensym 5))
(defun #:gensym (x)
(+ x arg))
This would be OK in a dynamically-scoped Lisp (in fact, I believe the
Maclisp compiler did exactly this), but not in Common Lisp. Your
definition should be equivalent to
I don't know of any compiler which did this. Maclisp's LET
was a macro (at least initially) that turned into LAMBDA in
the functional position like this; in other words, this was
Maclisp's ONLY way to get lexical variables other than arguments
in the argument list.
Maclisp did do something similar to what you describe when
the lambda was not in the functional position; i.e. when
you passed it as an argument. This meant you would have
had to declare ARG special to get the intended behaviour.
∂26-Mar-87 0301 RWK@YUKON.SCRC.Symbolics.COM Free variables in a LAMBDA which names a function
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Mar 87 03:01:22 PST
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 184420; Thu 26-Mar-87 05:57:35 EST
Date: Thu, 26 Mar 87 05:57 EST
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: Free variables in a LAMBDA which names a function
To: Barry Margolin <barmar@Think.COM>
cc: Stephen E. Robbins <STEVER%OZ.AI.MIT.EDU@xx.lcs.mit.edu>,
common-lisp@sail.stanford.edu
In-Reply-To: <870326004412.0.BARMAR@UBALDO.THINK.COM>
Supersedes: <870326055657.0.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Message-ID: <870326055735.1.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Thu, 26 Mar 87 00:44 EST
From: Barry Margolin <barmar@Think.COM>
My guess is that the compiler you are testing
translated the definition into:
(defun foo (arg)
(#:gensym 5))
(defun #:gensym (x)
(+ x arg))
This would be OK in a dynamically-scoped Lisp (in fact, I believe the
Maclisp compiler did exactly this), but not in Common Lisp. Your
definition should be equivalent to
I don't know of any compiler which did this. Maclisp's LET
was a macro (at least initially) that turned into LAMBDA in
the functional position like this; in other words, this was
Maclisp's ONLY way to get lexical variables other than arguments
in the argument list.
Maclisp did do something similar to what you describe when
the lambda was not in the functional position; i.e. when
you passed it as an argument. This meant you would have
had to declare ARG special to get the intended behaviour,
and no compiler warning about ARG appearing free inside
the LAMBDA.
∂26-Mar-87 0648 gls@Think.COM Replies to Extension to MAP
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Mar 87 06:48:48 PST
Received: from thoreau by Think.COM via CHAOS; Thu, 26 Mar 87 09:48:26 EST
Date: Thu, 26 Mar 87 09:48 EST
From: Guy Steele <gls@Think.COM>
Subject: Replies to Extension to MAP
To: Fahlman@c.cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <FAHLMAN.12289322220.BABYL@C.CS.CMU.EDU>
Message-Id: <870326094855.1.GLS@THOREAU.THINK.COM>
Date: Wed, 25 Mar 1987 20:03 EST
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
How about, if the first arg to MAP is an integer, it specifies
which argument should be clobbered? This doesn't allow an
unrelated sequence to be be clobbered, of course, but it does
allow the common case of an in-place MAP operation.
...
--Quux
This is a joke, right?
(defmacro --Quux () ':-)
...
The idea of extending MAP in a compatible way was cute, but dangerous:
it is usually a mistake to overload the same function to do two
fundamentally different things depending on some subtle type
distinction. If you want a destructive operation, you should ask for it
by name. Then if a sequence gets clobbered mysteriously, you have some
hope of finding the code responsible.
"The jam so disgusting, you can't say it on television. Ask for it by name!"
-- Fluckers Jam Commercial, Saturday Night Live
∂26-Mar-87 0728 gls@Think.COM Numerical Comparison: "required coercions"
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Mar 87 07:28:50 PST
Received: from thoreau by Think.COM via CHAOS; Thu, 26 Mar 87 10:28:42 EST
Date: Thu, 26 Mar 87 10:29 EST
From: Guy Steele <gls@Think.COM>
Subject: Numerical Comparison: "required coercions"
To: Moon@stony-brook.scrc.symbolics.com, Common-Lisp@sail.stanford.edu
Cc: Numerics@stony-brook.scrc.symbolics.com, gls@think.com
In-Reply-To: <870326005921.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870326102911.2.GLS@THOREAU.THINK.COM>
This issue makes me want to restate an earlier proposed model
for the comparison functions:
(? x1 x2 x3 x4 ... xn-1 xn) <=>
(AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn)
(? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn)
(? x3 x4) ... (? x3 xn-1) (? x3 xn)
. .
. .
.
(? xn-1 xn))
where "?" may be =, /=, <, >, <=, or >=.
That is, in principle every pair of arguments is compared.
This is the model that justifies the "all different" interpretation for /=,
and it is recognized that in practice the other five operations may
be implemented cleverly through exploitation of transitivity. Well,
maybe such reliance on transitivity is wrong.
--Guy
∂26-Mar-87 0806 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Mar 87 08:06:12 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70702; Thu 26-Mar-87 10:44:42 EST
Date: Thu, 26 Mar 87 10:47 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Numerical Comparison: "required coercions"
To: Guy Steele <gls@Think.COM>, Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@sail.stanford.edu
cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870326102911.2.GLS@THOREAU.THINK.COM>
Message-ID: <870326104752.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Thu, 26 Mar 87 10:29 EST
From: Guy Steele <gls@Think.COM>
This issue makes me want to restate an earlier proposed model
for the comparison functions:
(? x1 x2 x3 x4 ... xn-1 xn) <=>
(AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn)
(? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn)
(? x3 x4) ... (? x3 xn-1) (? x3 xn)
. .
. .
.
(? xn-1 xn))
where "?" may be =, /=, <, >, <=, or >=.
That is, in principle every pair of arguments is compared.
This is the model that justifies the "all different" interpretation for /=,
and it is recognized that in practice the other five operations may
be implemented cleverly through exploitation of transitivity. Well,
maybe such reliance on transitivity is wrong.
I'm a fan of transitivity and also recognize this problem. If this is
n↑2 computation is to be the law-of-the-land for the non /= cases, I
would suggest a declaration that tells the compiler that the user is
guaranteeing transitivity so that only a linear number of comparisons is
needed.
∂26-Mar-87 1048 @DIAMOND.S4CC.Symbolics.COM:Greenwald@STONY-BROOK.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Mar 87 10:48:38 PST
Received: from SWALLOW.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70790; Thu 26-Mar-87 13:34:59 EST
Date: Thu, 26 Mar 87 13:34 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Numerical Comparison: "required coercions"
To: DCP@QUABBIN.SCRC.Symbolics.COM, gls@Think.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp@sail.stanford.edu
cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870326104752.9.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Message-ID: <870326133440.1.GREENWALD@SWALLOW.S4CC.Symbolics.COM>
Date: Thu, 26 Mar 87 10:47 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Thu, 26 Mar 87 10:29 EST
From: Guy Steele <gls@Think.COM>
This issue makes me want to restate an earlier proposed model
for the comparison functions:
(? x1 x2 x3 x4 ... xn-1 xn) <=>
(AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn)
(? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn)
(? x3 x4) ... (? x3 xn-1) (? x3 xn)
. .
. .
.
(? xn-1 xn))
where "?" may be =, /=, <, >, <=, or >=.
That is, in principle every pair of arguments is compared.
This is the model that justifies the "all different" interpretation for /=,
and it is recognized that in practice the other five operations may
be implemented cleverly through exploitation of transitivity. Well,
maybe such reliance on transitivity is wrong.
Why "maybe"? (<= 1234d10 12340000000001 1234e10 12340000000000) => T
when you depend on transitivity, but should => NIL according to the
above model.
On the other hand, SORT clearly depends on transitivity, and one might
reasonably expect (APPLY '<= (SORT SEQUENCE '<=)) => T.
(Or even more reasonably (APPLY '< (SORT SEQUENCE '<)) => T, which
unfortunately isn't true since
(SORT '(1234d10 12340000000001 1234e10 12340000000000) '<) returns the
original sequence.)
I'm a fan of transitivity and also recognize this problem. If this is
n↑2 computation is to be the law-of-the-land for the non /= cases, I
would suggest a declaration that tells the compiler that the user is
guaranteeing transitivity so that only a linear number of comparisons is
needed.
The declaration is unnecessary, (although might be useful), since the
check for whether transitivity will work can be done in linear time.
(This same strategy reduces /= to NlogN for cases where transitivity
holds, and all the elements are orderable by sorting the numbers and
then only comparing adjacent elements. This doesn't work if any
coercions could lose precision. (This works for complex numbers, too))
In practice, our implementation assumes transitivity holds, except in
/=, where we are more scrupulous.
All these anomolies are solved by coercing to the *most* exact
representation for comparisons. I'm assuming that the floating-point
contagion rule was mandated for two reasons:
(1) It is misleading to *add* bits of precision during a computation.
(although this is belied by the single-to-double conversion rule)
(2) Floats put a stricter upper bound on the required storage than do
the corresponding rationals and bignums.
Both of these rules are more applicable for computations (+, -, etc.)
than for comparisons.
CLtL chose a single coercion rule ("WhenEVER a rational meets a floating
point number, the rational is first converted to a floating-point number
of the same format") rather than two coercion rules ("In computations
that produce new values, the arguments are first coerced to the least
precise representation of the two arguments, and the result has the
same, imprecise, representation. In comparisons, arguments that differ
in type are first converted to the *most* precise representation of the
two arguments.").
In some sense (although I don't believe this) you might be able to argue
that CLtL's decision made the language "simpler", (although it certainly
made the results of some of the numeric functions more "surprising").
If it isn't too late, maybe the coercion rule could be changed in the
"cleaned up Common Lisp". (Unless someone knows of equally bizarre
results of *that* coercion rule.)
∂26-Mar-87 1135 edsel!bhopal!jonl@navajo.stanford.edu Extension to MAP [if the shoe doesn't fit?]
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 11:35:20 PST
Received: by navajo.stanford.edu; Thu, 26 Mar 87 11:34:05 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA20686; Thu, 26 Mar 87 10:23:41 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA11122; Thu, 26 Mar 87 10:20:22 PST
Date: Thu, 26 Mar 87 10:20:22 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8703261820.AA11122@bhopal.edsel.com>
To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu
Cc: navajo!gls%THINK.COM@navajo.stanford.edu,
navajo!common-lisp%SAIL@navajo.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Wed, 25 Mar 1987 20:03 EST
Subject: Extension to MAP [if the shoe doesn't fit?]
How about, if the first arg to MAP is an integer, it specifies
which argument should be clobbered? This doesn't allow an
unrelated sequence to be be clobbered, of course, but it does
allow the common case of an in-place MAP operation.
This is a joke, right?
There are a number of places where the sequence functions are like
a size 15 shoe -- it just doesn't quite fit a lumber jack, and is
too non-specific for a ballerina.
Could I suggest that these "complaints" be considered evidence for
the need of a simple iteration paradigm? Each man can then cobble
his own shoe and wear it.
-- JonL --
∂26-Mar-87 1202 @DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Mar 87 12:02:30 PST
Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70837; Thu 26-Mar-87 14:58:18 EST
Date: Thu, 26 Mar 87 14:58 EST
From: Scott Cyphers <Cyphers@YUKON.SCRC.Symbolics.COM>
Subject: Numerical Comparison: "required coercions"
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM, DCP@QUABBIN.SCRC.Symbolics.COM,
gls@Think.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@sail.stanford.edu
cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870326133440.1.GREENWALD@SWALLOW.S4CC.Symbolics.COM>
Message-ID: <870326145812.3.CYPHERS@RAVEN.S4CC.Symbolics.COM>
Date: Thu, 26 Mar 87 13:34 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 26 Mar 87 10:47 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Thu, 26 Mar 87 10:29 EST
From: Guy Steele <gls@Think.COM>
This issue makes me want to restate an earlier proposed model
for the comparison functions:
(? x1 x2 x3 x4 ... xn-1 xn) <=>
(AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn)
(? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn)
(? x3 x4) ... (? x3 xn-1) (? x3 xn)
. .
. .
.
(? xn-1 xn))
where "?" may be =, /=, <, >, <=, or >=.
That is, in principle every pair of arguments is compared.
This is the model that justifies the "all different" interpretation for /=,
and it is recognized that in practice the other five operations may
be implemented cleverly through exploitation of transitivity. Well,
maybe such reliance on transitivity is wrong.
Why "maybe"? (<= 1234d10 12340000000001 1234e10 12340000000000) => T
when you depend on transitivity, but should => NIL according to the
above model.
On the other hand, SORT clearly depends on transitivity, and one might
reasonably expect (APPLY '<= (SORT SEQUENCE '<=)) => T.
(Or even more reasonably (APPLY '< (SORT SEQUENCE '<)) => T, which
unfortunately isn't true since
(SORT '(1234d10 12340000000001 1234e10 12340000000000) '<) returns the
original sequence.)
I'm a fan of transitivity and also recognize this problem. If this is
n↑2 computation is to be the law-of-the-land for the non /= cases, I
would suggest a declaration that tells the compiler that the user is
guaranteeing transitivity so that only a linear number of comparisons is
needed.
The declaration is unnecessary, (although might be useful), since the
check for whether transitivity will work can be done in linear time.
(This same strategy reduces /= to NlogN for cases where transitivity
holds, and all the elements are orderable by sorting the numbers and
then only comparing adjacent elements. This doesn't work if any
coercions could lose precision. (This works for complex numbers, too))
In practice, our implementation assumes transitivity holds, except in
/=, where we are more scrupulous.
All these anomolies are solved by coercing to the *most* exact
representation for comparisons. I'm assuming that the floating-point
contagion rule was mandated for two reasons:
(1) It is misleading to *add* bits of precision during a computation.
(although this is belied by the single-to-double conversion rule)
(2) Floats put a stricter upper bound on the required storage than do
the corresponding rationals and bignums.
Both of these rules are more applicable for computations (+, -, etc.)
than for comparisons.
CLtL chose a single coercion rule ("WhenEVER a rational meets a floating
point number, the rational is first converted to a floating-point number
of the same format") rather than two coercion rules ("In computations
that produce new values, the arguments are first coerced to the least
precise representation of the two arguments, and the result has the
same, imprecise, representation. In comparisons, arguments that differ
in type are first converted to the *most* precise representation of the
two arguments.").
In some sense (although I don't believe this) you might be able to argue
that CLtL's decision made the language "simpler", (although it certainly
made the results of some of the numeric functions more "surprising").
If it isn't too late, maybe the coercion rule could be changed in the
"cleaned up Common Lisp". (Unless someone knows of equally bizarre
results of *that* coercion rule.)
Leave things the way they are. You're trying to give too much meaning
to something which only derives its meaning from the way it is being
used. In normal situations, things behave about how you'd expect them
to. It is only when you get into the noise that things fall apart,
because the multiple interpretations are no longer distinct. In those
cases, I say it is an error to write something like (< x rational), and
that you have no right to expect something like transitivity to hold
because you're mixing definitions. If you want to say <, then do the
coercions yourself in the way appropriate to what your working on.
Rationals aren't necessarily any more exact than floating point. If
you're computing rationals, then they're exact, but if you're computing
reals, then they're no more exact than floating point. What if someone
is trying to say (< x (sqrt 2))? Unless they are doing their own
coercions (or squaring x) I think there's always going to be some form
of default coercion which will do the "unexpected" for them.
∂26-Mar-87 1137 edsel!bhopal!jonl@navajo.stanford.edu Free variables in a LAMBDA which names a function
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 11:36:58 PST
Received: by navajo.stanford.edu; Thu, 26 Mar 87 11:35:15 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA20788; Thu, 26 Mar 87 10:54:27 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA11230; Thu, 26 Mar 87 10:51:09 PST
Date: Thu, 26 Mar 87 10:51:09 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8703261851.AA11230@bhopal.edsel.com>
To: navajo!barmar%Think.COM@navajo.stanford.edu
Cc: navajo!STEVER%OZ.AI.MIT.EDU%xx.lcs.mit.edu@navajo.stanford.edu,
navajo!common-lisp%sail@navajo.stanford.edu
In-Reply-To: Barry Margolin's message of Thu, 26 Mar 87 00:44 EST
Subject: Free variables in a LAMBDA which names a function
Re: This would be OK in a dynamically-scoped Lisp (in fact, I believe the
Maclisp compiler did exactly this), but not in Common Lisp. Your
definition should be equivalent to . . .
No, MacLisp never yanked internal lambda applications out of lexical
environment -- both it and Interlisp "did the right thing" in the
case of a function like:
(defun foo (arg)
((lambda (x) (+ x arg)) 5))
Probably you are remembering how both MacLisp and Interlisp would yank
an #'(lambda (x) ...) out of lexical context, and make it into a defun
with gensym'd name.
A point not sufficiently appreciated is that both MacLisp and Common
Lisp are *both* lexically and dynamically scoped. For MacLisp, you
will find that:
(1) had a bug in the interpreter in that local variables weren't
treated lexically, as they were by the compiler.
(2) couldn't handle lexical functions at all. [Note how "lexical
functions" differs from "lambda form applications"].
CLtL Chapter 3 is an excellent treatise on the issue of scope -- I
highly recommend re-reading it for anyone who hasn't done so recently.
(1) was a persistent misfeature of MacLisp, which everyone adjusted to
with some amount of grumbling. Interestingly, Interlisp considered (1)
to be a major feature, and its compiler was modified to match!
(2) was addressed by the Scheme papers. This, in fact, is probably
the most innovative feature of Common Lisp that didn't originate from
either MacLisp or ZetaLisp [although VAX/NIL made a stab at implementing
something like it]. Giving up any closure over dynamic variables was
an aggressive step back then. Full closure over the environment (both
lexical and dynamic) required "spaghetti stacks" -- see paper by Dan
Bobrow circa 1974. ZetaLisp and NIL had the notion of limited dynamic
closures, but these seemed to require "hard" implementation techniques
for limited advantage over simply "lexical closures".
-- JonL --
∂26-Mar-87 1137 edsel!bhopal!jonl@navajo.stanford.edu Numerical Comparison: "required coercions"
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 11:37:37 PST
Received: by navajo.stanford.edu; Thu, 26 Mar 87 11:35:52 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
id AA20846; Thu, 26 Mar 87 11:13:38 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
id AA11270; Thu, 26 Mar 87 11:10:18 PST
Date: Thu, 26 Mar 87 11:10:18 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8703261910.AA11270@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!Common-Lisp%sail@navajo.stanford.edu,
navajo!Numerics%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu,
navajo!fateman%mike.Berkeley.EDU.navajo!gls%Think.COM@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 26 Mar 87 00:59 EST
Subject: Numerical Comparison: "required coercions"
Having spoken with a number of Lisp users (as opposed to implementors),
the overwhelming consensus appears to be that "=" must act like a
transitive operation. I should think that this statement alone would
be sufficient to clarify sections 12.1 to 12.4 of CLtL. Thus the
phrase "required coercions" would have to take on a context-sensitive
interpretation -- certain kinds of coercions are required when doing
comparisons, others are required when doing operations like addition
and multiplication.
I don't propose to fix up the inherent non-associativity of
floating-point addition and multiplication; this "feature" is a
consequence of truncating information (i.e., "rounding" by whatever
rule) in order to return a result in the required format. Note,
however, that the comparison functions return a boolean value -- not
a floating-point value -- and hence aren't subject to the same problems.
So I would think that differing kinds of coercions between the two
kinds of operations wouldn't violate reasonable expectations.
You're quite right that if IEEE specifies what to do when comparing
floats of differing precisions (e.g., single-float with double-float)
then we ought to go for that. I don't know what it says. How about
it Richard J. Fateman, you usually know about these matters?
-- JonL --
∂26-Mar-87 1208 gls@Think.COM Re: Numerical Comparison: "required coercions"
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Mar 87 12:08:23 PST
Received: from thoreau by Think.COM via CHAOS; Thu, 26 Mar 87 15:08:11 EST
Date: Thu, 26 Mar 87 15:08 EST
From: Guy Steele <gls@Think.COM>
Subject: Re: Numerical Comparison: "required coercions"
To: fateman@mike.berkeley.edu, Common-Lisp@sail.stanford.edu,
DCP@quabbin.scrc.symbolics.com,
Greenwald@stony-brook.scrc.symbolics.com,
Moon@stony-brook.scrc.symbolics.com, gls@think.com
Cc: Numerics@stony-brook.scrc.symbolics.com, gls@think.com
In-Reply-To: <8703261954.AA05911@mike>
Message-Id: <870326150845.8.GLS@THOREAU.THINK.COM>
Date: Thu, 26 Mar 87 11:54:28 PST
From: fateman@mike.berkeley.edu (Richard Fateman)
I think that comparing more than 2 operands could simply be
forbidden since the semantics is unclear and the utility
is doubtful.
The convenience is considerable when working with integers in
such expressions as
(<= 0 J N)
(< -1 J K (+ N 1))
Admittedly this does not allow similarly concise expression of such common
mathematical idioms as 0 <= j < n where the comparisons differ as to
whether equality is to be included.
I agree that using more than two arguments with floating-point
numbers should perhaps be avoided as a matter of style.
--Guy
∂26-Mar-87 1225 fateman@mike.Berkeley.EDU Re: Numerical Comparison: "required coercions"
Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 12:24:58 PST
Received: by ucbvax.Berkeley.EDU (5.57/1.23)
id AA21122; Thu, 26 Mar 87 11:55:09 PST
Received: by mike (3.2/5.17)
id AA05911; Thu, 26 Mar 87 11:54:28 PST
Date: Thu, 26 Mar 87 11:54:28 PST
From: fateman@mike.Berkeley.EDU (Richard Fateman)
Message-Id: <8703261954.AA05911@mike>
To: Common-Lisp@sail.stanford.edu, DCP@quabbin.scrc.symbolics.com,
Greenwald@stony-brook.scrc.symbolics.com,
Moon@stony-brook.scrc.symbolics.com, gls@think.com
Subject: Re: Numerical Comparison: "required coercions"
Cc: Numerics@stony-brook.scrc.symbolics.com
I think that comparing more than 2 operands could simply be
forbidden since the semantics is unclear and the utility
is doubtful.
I disagree with the statement that "it is misleading to
*add* bits of precision during a computation." In fact,
unless the language starts by assuming that ALL
numbers, floating point numbers or rationals are exact,
you are in trouble. (Some languages screw this up,
and perhaps this is where the inspiration comes from.)
The best model might be to say that changing representations
(e.g. float to double conversion) is fine, as long
as it doesn't change the value.
But rational to float sometimes changes values
(sometimes it loses the whole ball of wax when the
number over/underflows). This is not good.
....
Confusing accuracy with precision is dangerous.
No one knows for sure that 1/3 is more accurate than
0.3. In fact, they may both be used as poor approximations
to 1/2.
....
There is an IEEE "inexact" flag which pertain to operations,
not operands. It helps you do things in lower precision
than you thought you could, and still get the right answer.
More later.,.
∂26-Mar-87 1351 Moon@STONY-BROOK.SCRC.Symbolics.COM Re: Numerical Comparison: "required coercions"
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 26 Mar 87 13:51:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 102278; Thu 26-Mar-87 16:33:29 EST
Return-path: <@UCB-VAX.ARPA:fateman@mike.Berkeley.EDU>
Received: from ucbvax.Berkeley.EDU (UCB-VAX.ARPA) by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 101751; 26 Mar 87 05:27:49 EST
Received: by ucbvax.Berkeley.EDU (5.57/1.23)
id AA11161; Wed, 25 Mar 87 23:21:10 PST
Received: by mike (3.2/5.17)
id AA05372; Wed, 25 Mar 87 23:18:49 PST
Date: Wed, 25 Mar 87 23:18:49 PST
From: fateman@mike.Berkeley.EDU (Richard Fateman)
Message-Id: <8703260718.AA05372@mike>
To: Moon@stony-brook.scrc.symbolics.com
Subject: Re: Numerical Comparison: "required coercions"
Resent-To: Common-Lisp@sail.stanford.edu
Resent-From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Thu, 26 Mar 87 16:33 EST
Resent-Message-ID: <870326163309.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
mixed mode is not covered in IEEE standard. The assumption of
most people is, I think that the smaller format is zero-extended
and then compared. Rational numbers are not part of the IEEE
standard, and that is where jonl's point comes up. This was
discussed a year ago, or so.
∂26-Mar-87 1545 @DIAMOND.S4CC.Symbolics.COM:Greenwald@STONY-BROOK.SCRC.Symbolics.COM Numerical Comparison: "required coercions"
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 26 Mar 87 15:45:30 PST
Received: from SWALLOW.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 70959; Thu 26-Mar-87 17:29:44 EST
Date: Thu, 26 Mar 87 17:29 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Numerical Comparison: "required coercions"
To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM, DCP@QUABBIN.SCRC.Symbolics.COM,
gls@Think.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@sail.stanford.edu
cc: Numerics@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870326133440.1.GREENWALD@SWALLOW.S4CC.Symbolics.COM>
Message-ID: <870326172927.6.GREENWALD@SWALLOW.S4CC.Symbolics.COM>
Date: Thu, 26 Mar 87 13:34 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 26 Mar 87 10:47 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Thu, 26 Mar 87 10:29 EST
From: Guy Steele <gls@Think.COM>
This issue makes me want to restate an earlier proposed model
for the comparison functions:
(? x1 x2 x3 x4 ... xn-1 xn) <=>
(AND (? x1 x2) (? x1 x3) (? x1 x4) ... (? x1 xn-1) (? x1 xn)
(? x2 x3) (? x2 x4) ... (? x2 xn-1) (? x2 xn)
(? x3 x4) ... (? x3 xn-1) (? x3 xn)
. .
. .
.
(? xn-1 xn))
where "?" may be =, /=, <, >, <=, or >=.
That is, in principle every pair of arguments is compared.
This is the model that justifies the "all different" interpretation for /=,
and it is recognized that in practice the other five operations may
be implemented cleverly through exploitation of transitivity. Well,
maybe such reliance on transitivity is wrong.
Why "maybe"? (<= 1234d10 12340000000001 1234e10 12340000000000) => T
when you depend on transitivity, but should => NIL according to the
above model.
On the other hand, SORT clearly depends on transitivity, and one might
reasonably expect (APPLY '<= (SORT SEQUENCE '<=)) => T.
(Or even more reasonably (APPLY '< (SORT SEQUENCE '<)) => T, which
unfortunately isn't true since
(SORT '(1234d10 12340000000001 1234e10 12340000000000) '<) returns the
original sequence.)
I was wrong. The < case isn't a reasonable expectation. Mike McMahon
points out: (APPLY '< (SORT '(1 1 1 1 1 1 1) '<)). I guess I wasn't
thinking too clearly.
∂26-Mar-87 1717 REM@IMSSS Coercion rule for comparisons
Received: from IMSSS by SAIL with PUP; 26-Mar-87 17:17 PST
Date: 26 Mar 1987 1714-PST
From: Rem@IMSSS
Subject: Coercion rule for comparisons
To: COMMON-LISP@SU-AI
Perhaps the rule for binary (two-arg) comparison should be first coerced
to least-accurate (a la arithmetic) to see if they can be distinguished
(shown non-equal) at that level of precision. If so, we can immediately
answer the pending question at minimal cost. If they look equal at
least precision, then coerce the other way (most precision) to get
a definitive result.
If that were the rule for binary comparisons, would transitivity then
hold for all the standard comparison operations except not-equal?
-------
∂26-Mar-87 2139 VERACSD@A.ISI.EDU NMAP
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Mar 87 21:39:39 PST
Date: 27 Mar 1987 00:38-EST
Sender: VERACSD@A.ISI.EDU
Subject: NMAP
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: fahlman@C.CS.CMU.EDU, veracsd.rs@A.ISI.EDU
Message-ID: <[A.ISI.EDU]27-Mar-87 00:38:32.VERACSD>
(defun nmap (result-sequence function &rest sequences)
(let ((length (length result-sequence))
(arguments (make-list (length sequences)))
(rs result-sequence)
result-element)
(dolist (sequence sequences)
(setq length (min length (length sequence))))
(dotimes (index length)
(do* ((args arguments (cdr args))
(seqs sequences (cdr seqs))
(sequence (car sequences) (car seqs)))
((null args))
(setf (car args)
(cond ((listp sequence)
(setf (car seqs) (cdr sequence))
(car sequence))
(t
(aref sequence index)))))
(setq result-element (apply function arguments))
(cond ((listp result-sequence)
(setf (car rs) result-element)
(setq rs (cdr rs)))
(t
(setf (aref result-sequence index) result-element))))
result-sequence))
I have pursued this simply because I have found nmap to be quite
useful. For example, to fill a sequence with random numbers, one can
use (nmap sequence #'(lambda () (random 1.0))). (This also illustrates
that nmap may take zero additional sequence arguments.) I'd like to
encourage Symbolics, TI, et al. to add this as an extension.
Note that nmap is a function rather than a macro. This is surely
the right thing.
I was able to reduce the consing only down to M cells, where M is
the number of additional sequences passed, while still remaining within
Common Lisp. Lisp machines can reduce it to zero.
Probably this code can be improved in other ways, but it is
competitive with map on the Explorer. (Our Symbolics crashed earlier
today).
Caveat emptor: I only just wrote this version, so there could
*conceivably* be a bug or two, although I tested it. I also had to type
it in by hand on a Mac.
(Incidentally, Scott, I found it far from trivial to come up with
a macro that correctly implements nmap with no consing. In fact, after
a while I decided to give up on it. If you decide to do it for fun,
I'd like to see the result.)
Bob Sasseen
veracsd.rs@a.isi.edu (arpanet)
∂27-Mar-87 0136 mcvax!lifia!phs@seismo.CSS.GOV Practical (values)
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 27 Mar 87 01:35:53 PST
Received: from mcvax.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA27017; Fri, 27 Mar 87 04:36:37 EST
Received: by mcvax.cwi.nl; Fri, 27 Mar 87 10:28:21 +0100 (MET)
Received: by inria.inria.fr; Fri, 27 Mar 87 09:24:00 +0100 (MET)
Received: by imag.UUCP; Fri, 27 Mar 87 09:13:24 -0200 (MET)
Received: by lifia.UUCP; Fri, 27 Mar 87 09:09:11 -0200 (MET)
Date: Fri, 27 Mar 87 09:09:11 -0200
From: mcvax!lifia!phs@seismo.CSS.GOV (Philippe Schnoebelen)
Message-Id: <8703270709.AA19189@lifia.UUCP>
To: common-lisp@sail.stanford.edu
Subject: Practical (values)
I am always wondering about the multiple-values feature of CommonLisp,
more specially the possibility of returning NO values, through a (VALUES)
form.
Very often one defines a function which does not return any informative
value (at least it is only meant to have a side effect, but the value that
happens to be returned should be irrelevant). This is a situation where I
am tempted to put a (VALUES) form a the end of the function body. It is
certainly cleaner and it should not compile into less efficient code, at
least "there is no reason why it should give worse code" (the usual
incantation). Yes, but practically ?
Could someone give me (us) explanations about this ? How is it usually
implemented ? Is it more, less, equally efficient ? Only in connection with
(OPTIMIZE ...) declarations ? (TYPE ...) declarations ?
Thanks.
--
Philippe SCHNOEBELEN,
LIFIA - IMAG, BP 68 UUCP : ...mcvax!imag!lifia!phs
38402 Saint Martin d'Heres, FRANCE
"Algebraic symbols are used when you do not know what you are talking about."
∂27-Mar-87 0740 FAHLMAN@C.CS.CMU.EDU Practical (values)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87 07:39:54 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 27 Mar 87 10:42:15-EST
Date: Fri, 27 Mar 1987 10:42 EST
Message-ID: <FAHLMAN.12289744383.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: mcvax!lifia!phs@λseismo.CSS.GOV (Philippe Schnoebelen)λ
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Practical (values)
In-reply-to: Msg of Fri 27 Mar 87 09:09:11 -0200 from mcvax!lifia!phs at seismo.CSS.GOV (Philippe Schnoebelen)
I think that you will find that a lot of Common Lisp implementations
handle one return value somewhat more efficiently than they handle zero
values. There are two reasons for this: first, many implementations are
adaptations of older Lisp systems that had only single-value returns,
and the multiple value stuff was grafted on as an afterthought; second,
many newer implementations handle single-value return as a special case
that is carefully tuned for greatest performance, since the overwhelming
majority of Common Lisp calls (measured dynamically) either return only
a single value or immediately discard any additional values. In some
implementations, returning NIL and returning (VALUES) may be equally
fast, but I don't know of any in which the latter form would be faster.
I suppose one could argue that returning (VALUES) is more perspicuous,
since it makes clear that the return value is of no interest. But the
practice of returning NIL in such cases is a time-honored idom that is
unlikely to confuse anyone; a lot of people would have to stop and
consider what (VALUES) means.
-- Scott
∂27-Mar-87 1312 VERACSD@A.ISI.EDU NMAP macro
Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Mar 87 13:12:11 PST
Date: 27 Mar 1987 16:12-EST
Sender: VERACSD@A.ISI.EDU
Subject: NMAP macro
From: VERACSD@A.ISI.EDU
To: common-lisp@SAIL.STANFORD.EDU
Cc: fahlman@C.CS.CMU.EDU, veracsd.rs@A.ISI.EDU
Message-ID: <[A.ISI.EDU]27-Mar-87 16:12:34.VERACSD>
(defmacro nmap (result-sequence function &rest sequences)
(let (let-clauses min-args function-args
gs
(result-sequence-gs (gensym))
(function-gs (gensym))
(length (gensym))
(rs (gensym))
(result-element (gensym))
(index (gensym)))
(dolist (sequence (reverse sequences))
(setq gs (gensym))
(push '(,gs ,sequence) let-clauses)
(push '(cond ((listp ,gs)
(pop ,gs))
(t
(aref ,gs ,index)))
function-args)
(push '(length ,gs) min-args))
(push '(,function-gs ,function) let-clauses)
(push '(,result-sequence-gs ,result-sequence) let-clauses)
(push '(length ,result-sequence-gs) min-args)
'(let (,@let-clauses
(,length (length ,result-sequence-gs))
(,rs ,result-sequence-gs)
,result-element)
(setq ,length (funcall 'min ,@min-args))
(dotimes (,index ,length)
(setq ,result-element (funcall ,function-gs ,@function-args))
(cond ((listp ,result-sequence-gs}i)
(setf (car ,rs) ,result-element)
(setq ,rs (cdr ,rs)))
(t
(setf (aref ,result-sequence-gs ,index) ,result-element))))
,result-sequence-gs)))
For those who prefer a macro. Don't know why I couldn't come up
with this last night.
Bob Sasseen
veracsd.rs@a.isi.edu (arpanet)
∂27-Mar-87 2225 MURRAY%cs.umass.edu@RELAY.CS.NET NMAP a good idea.
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Mar 87 22:25:27 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa04969; 28 Mar 87 1:19 EST
Received: from cs.umass.edu by RELAY.CS.NET id ca12707; 28 Mar 87 1:14 EST
Date: Fri, 27 Mar 87 17:46 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: NMAP a good idea.
X-VMS-To: CSNET%"common-lisp@su-ai.ARPA"
I think the NMAP function is an excellent idea. Mapping is generally
a good way to express things, and lends itself to parallelism.
However, I would call the proposed function MAP-INTO, and
have provided a definition below. The definition provided
by Sasseen has the same Bug that most implementations
have with some sequence functions - they call LENGTH
on the arguments, which will never return for circular lists.
By having it be a macro instead of a function, it performs
NO consing, since the number of arguments are known,
and FUNCALL can be used. However, it suffers the macro problem,
in that macros cannot be APPLYed.
The right way to do it is to have it be a function that
has a compiler transform to expand calls at compile time.
Unfortunately, compiler transforms are not part of Common Lisp.
BTW: It took me 2 hours to write and debug this macro.
-- Kelly Murray
(defmacro MAP-INTO (into-seq function &rest arg-seqs)
"MAP-INTO into-seq function &rest arg-seqs
Calls function on each element of the arg-seqs, storing results
in corresponding element of into-seq. Returns modified into-seq."
(let* ((rs-sym (gensym "RS-SYM"))
(seq-syms (mapcar
#'(lambda (ignore) (gensym "SEQ"))
arg-seqs))
(consp-syms (mapcar
#'(lambda (ignore) (gensym "SEQ-CONSP"))
arg-seqs))
(rs-size (gensym "RS-SIZE"))
(rs-cons (gensym "RS-CONS"))
(seq-index (gensym "SEQ-INDEX"))
(max-sym (gensym "MAX-INDEX"))
(result-sym (gensym "RESULT"))
(fun-sym (gensym "FUN")))
;; First Eval the arguments.
`(let* ((,rs-sym ,into-seq)
(,fun-sym ,function)
,@(mapcar #'(lambda(sym seq)(list sym seq))
seq-syms arg-seqs)
; Determine result type
(,rs-cons (when (consp ,rs-sym) ,rs-sym))
(,rs-size (unless ,rs-cons (length ,rs-sym)))
,@(mapcar #'(lambda(sym seq)(list sym `(consp ,seq)))
consp-syms seq-syms) ; Consp variables
(,max-sym nil)
(,result-sym nil)
)
;; Determine maximum index for any argument vectors.
,@(mapcar
#'(lambda(sym consp)
`(unless ,consp
(if ,max-sym
(setq ,max-sym (min ,max-sym (length ,sym)))
(setq ,max-sym (length ,sym)))))
seq-syms
consp-syms)
(or ,max-sym (setq ,max-sym -1)) ; = never true for conses
(do ((,seq-index 0 (1+ ,seq-index)))
((or (= ,seq-index ,max-sym) ; Hit smaller
,@(mapcan
#'(lambda (sym)
`((not ,sym))) ; End of a List.
seq-syms))
,rs-sym) ; Return the result sequence.
;; Call the function.
(setq ,result-sym
(funcall ,fun-sym
,@(mapcar #'(lambda(sym consp)
`(if ,consp (pop ,sym)
(elt ,sym ,seq-index)))
seq-syms
consp-syms)))
;; Store the results
(cond
(,rs-cons
(setf (car ,rs-cons) ,result-sym)
(pop ,rs-cons))
((< ,seq-index ,rs-size)
(setf (elt ,rs-sym ,seq-index) ,result-sym)))
))))
∂27-Mar-87 2226 MURRAY%cs.umass.edu@RELAY.CS.NET NMAP a good idea if done correctly (blush)
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Mar 87 22:25:44 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab04968; 28 Mar 87 1:19 EST
Received: from cs.umass.edu by RELAY.CS.NET id cb12707; 28 Mar 87 1:15 EST
Date: Fri, 27 Mar 87 18:48 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp%su-ai.arpa@RELAY.CS.NET
Subject: NMAP a good idea if done correctly (blush)
X-VMS-To: CSNET%"common-lisp@su-ai.ARPA"
I think the NMAP function is an excellent idea. Mapping is generally
a good way to express things, and lends itself to parallelism.
However, I would call the proposed function MAP-INTO, and
have provided a definition below. The definition provided
by Sasseen has the same Bug that most implementations
have with some sequence functions - they call LENGTH
on the arguments, which will never return for circular lists.
By having it be a macro instead of a function, it performs
NO consing, since the number of arguments are known,
and FUNCALL can be used. However, it suffers the macro problem,
in that macros cannot be APPLYed.
The right way to do it is to have it be a function that
has a compiler transform to expand calls at compile time.
Unfortunately, compiler transforms are not part of Common Lisp.
BTW: It took me 2 hours and 10 minutes to write and debug this macro.
-- Kelly Murray
(defmacro MAP-INTO (into-seq function &rest arg-seqs)
"MAP-INTO into-seq function &rest arg-seqs
Calls function on each element of the arg-seqs, storing results
in corresponding element of into-seq. Returns modified into-seq."
(let* ((rs-sym (gensym "RS-SYM"))
(seq-syms (mapcar
#'(lambda (ignore) (gensym "SEQ"))
arg-seqs))
(consp-syms (mapcar
#'(lambda (ignore) (gensym "SEQ-CONSP"))
arg-seqs))
(rs-size (gensym "RS-SIZE"))
(rs-cons (gensym "RS-CONS"))
(seq-index (gensym "SEQ-INDEX"))
(max-sym (gensym "MAX-INDEX"))
(result-sym (gensym "RESULT"))
(fun-sym (gensym "FUN")))
(cond
((null arg-seqs) ; No arguments?
`(let* ((,rs-sym ,into-seq)
(,fun-sym ,function)
(,rs-cons (consp ,rs-sym)))
(when ,rs-sym ; Not NIL
(if ,rs-cons
(do ((,rs-cons ,rs-sym (cdr ,rs-cons)))
((endp ,rs-cons) ,rs-sym)
(setf (car ,rs-cons) (funcall ,fun-sym)))
(dotimes (,rs-size (length ,rs-sym) ,rs-sym)
(setf (elt ,rs-sym ,rs-size) (funcall ,fun-sym))))
)))
(:Else
;; First Eval the arguments.
`(let* ((,rs-sym ,into-seq)
(,fun-sym ,function)
,@(mapcar #'(lambda(sym seq)(list sym seq))
seq-syms arg-seqs)
; Determine result type
(,rs-cons (when (consp ,rs-sym) ,rs-sym))
(,rs-size (unless ,rs-cons (length ,rs-sym)))
,@(mapcar #'(lambda(sym seq)(list sym `(consp ,seq)))
consp-syms seq-syms) ; Consp variables
(,max-sym nil)
(,result-sym nil)
)
;; Determine maximum index for any argument vectors.
,@(mapcar
#'(lambda(sym consp)
`(unless ,consp
(if ,max-sym
(setq ,max-sym (min ,max-sym (length ,sym)))
(setq ,max-sym (length ,sym)))))
seq-syms
consp-syms)
(or ,max-sym (setq ,max-sym -1)) ; = never true for conses
(do ((,seq-index 0 (1+ ,seq-index)))
((or (= ,seq-index ,max-sym) ; Hit smaller
,@(mapcan
#'(lambda (sym)
`((not ,sym))) ; End of a List.
seq-syms))
,rs-sym) ; Return the result sequence.
;; Call the function.
(setq ,result-sym
(funcall ,fun-sym
,@(mapcar #'(lambda(sym consp)
`(if ,consp (pop ,sym)
(elt ,sym ,seq-index)))
seq-syms
consp-syms)))
;; Store the results
(cond
(,rs-cons
(setf (car ,rs-cons) ,result-sym)
(pop ,rs-cons))
((< ,seq-index ,rs-size)
(setf (elt ,rs-sym ,seq-index) ,result-sym)))
))))
))
∂28-Mar-87 0702 FAHLMAN@C.CS.CMU.EDU NMAP a good idea.
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 28 Mar 87 07:01:58 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 28 Mar 87 10:02:47-EST
Date: Sat, 28 Mar 1987 10:02 EST
Message-ID: <FAHLMAN.12289999345.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MURRAY%cs.umass.edu@RELAY.CS.NET
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: NMAP a good idea.
In-reply-to: Msg of 27 Mar 1987 16:46-EST from MURRAY%cs.umass.edu at RELAY.CS.NET
Just so that your message will not cause a flood of bug reports to
Common Lisp implementors:
It has not been established that it is a bug for sequence functions not
to handle circular lists. There seems to be strong sentiment on both
sides of this issue, and there is no clear statement on this in the
manual. At some point the standardization committee will have to make a
decision one way or the other.
If it were up to me (which it isn't) it would be an error to pass a
circular list to any function that does not explicitly allow circular
lists. I don't think the extra cost of handling this style is justified
for most functions. Sequences should be finite.
-- Scott
∂28-Mar-87 0828 frascado@umn-cs.arpa nmap
Received: from UMN-CS.ARPA by SAIL.STANFORD.EDU with TCP; 28 Mar 87 08:27:54 PST
Received: by umn-cs.arpa (5.51/4.7)
id AA28737; Sat, 28 Mar 87 10:28:55 CST
Date: Sat, 28 Mar 87 10:28:55 CST
From: frascado@umn-cs.arpa (Gregory Frascadore)
Message-Id: <8703281628.AA28737@umn-cs.arpa>
To: common-lisp@sail.stanford.edu
Subject: nmap
Here is another version of an nmap macro that I think addresses the
problems with length vs circular lists:
(defmacro nmap (seq fun &rest seqs)
(let ((arglist (mapcar #'(lambda (dummy) (gensym)) seqs)) )
`(let ((i 0)
(rseq ,seq) )
(map nil
#'(lambda ,(cons (gensym) arglist)
(setf (elt rseq i) (funcall ,fun ,@arglist))
(incf i) )
rseq ,@seqs )
rseq )))
-------
Gregory Frascadore
Computer Science Department frascado%umn-cs.csnet@csnet-relay.arpa
University of Minnesota frascado@umn-cs
∂28-Mar-87 1202 pyramid!pyramid.UUCP!bein@hplabs.HP.COM Sequence functions ..
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 28 Mar 87 12:02:05 PST
Received: by hplabs.HP.COM ; Sat, 28 Mar 87 12:02:42 pst
Received: by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86)
id AA21125; Sat, 28 Mar 87 11:35:42 PST
Date: 28 Mar 1987 11:20-PST
From: David Bein <pyramid!bein@hplabs.HP.COM>
Subject: Sequence functions ..
To: hplabs!common-lisp@su-ai@hplabs.HP.COM
Message-Id: <543957653/bein@pyramid>
While we are at it, is a list which is terminated by something besides
nil considered a legal sequence? My opinion is that a sequence
should be properly terminated and as a result, length is legitimate
when it complains about improperly terminated lists. Also, what
seems to be the consensus about circular lists and sequence functions?
I agree with Scott that a function which is not advertised to handle
circular lists should be allowed to loop/recurse. My current
implementation of length uses list-length, but I think this is overly
expensive and would prefer to use a more tradition definition which
uses either ENDP or ATOM to stop.
--David
∂29-Mar-87 1345 sandra%utah-orion@utah-cs.arpa *terminal-io*
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 29 Mar 87 13:45:11 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA05375; Sun, 29 Mar 87 14:47:53 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA00699; Sun, 29 Mar 87 14:47:49 MST
Date: Sun, 29 Mar 87 14:47:49 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8703292147.AA00699@utah-orion.ARPA>
Subject: *terminal-io*
To: common-lisp@sail.stanford.edu
CLtL specifies that *standard-input*, *standard-output*, and friends should
initially be bound to synonym streams that pass everything on to *terminal-io*.
In the very next paragraph (p329), however, it says that the value of
*terminal-io* should never be changed. What is the point of introducing the
extra level of indirection? Is there some reason why *standard-input*
couldn't be initialized to the same stream as *terminal-io*?
-Sandra
-------
∂29-Mar-87 1415 smh@EMS.MEDIA.MIT.EDU Re: *terminal-io*
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Mar 87 14:15:28 PST
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA22633; Sun, 29 Mar 87 17:16:00 EST
Date: Sun, 29 Mar 87 17:16:00 EST
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8703292216.AA22633@EMS.MEDIA.MIT.EDU>
To: common-lisp@sail.stanford.edu, sandra%utah-orion@utah-cs.arpa
Subject: Re: *terminal-io*
CLtL actually says: "No **user** program should ever change the
value of *terminal-io*." [emphasis added] Presumably it is
allowable for **environment** managing code such as a window
manager to play with *terminal-io* in a multiple process
environment. Details left as an exercise for the implementor ...
∂29-Mar-87 1625 sandra%utah-orion@utah-cs.arpa Re: *terminal-io*
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 29 Mar 87 16:25:25 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA10186; Sun, 29 Mar 87 17:28:08 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA01022; Sun, 29 Mar 87 17:28:03 MST
Date: Sun, 29 Mar 87 17:28:03 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Message-Id: <8703300028.AA01022@utah-orion.ARPA>
Subject: Re: *terminal-io*
To: smh@ems.media.mit.edu (Steven Haflich)
Cc: common-lisp@sail.stanford.edu, sandra%utah-orion@utah-cs.arpa
In-Reply-To: smh@EMS.MEDIA.MIT.EDU (Steven Haflich), Sun, 29 Mar 87 17:16:00 EST
Well, suppose the implementation doesn't provide any utilities that mess with
the value of *terminal-io*: it might initialize it on startup and that's
that. If *terminal-io* is never changed in system code, and users aren't
supposed to change it, why bother with the synonym stream? I think the manual
is being overly restrictive here....
-Sandra
-------
∂29-Mar-87 2055 KMP@STONY-BROOK.SCRC.Symbolics.COM *terminal-io*
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Mar 87 20:55:13 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 104021; Sun 29-Mar-87 22:07:13 EST
Date: Sun, 29 Mar 87 22:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *terminal-io*
To: sandra%utah-orion@UTAH-CS.ARPA
cc: smh@ems.media.mit.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8703300028.AA01022@utah-orion.ARPA>
Message-ID: <870329220557.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Sun, 29 Mar 87 17:28:03 MST
From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore)
Well, suppose the implementation doesn't provide any utilities
that mess with the value of *terminal-io*: it might initialize
it on startup and that's that. If *terminal-io* is never changed
in system code, and users aren't supposed to change it, why bother
with the synonym stream? I think the manual is being overly
restrictive here....
The responsibility of CL goes beyond legislating simply what
implementations must and must not do for the sake of user code. It tries
to create formalisms where reasonable implementation-dependent
extensions to the language will not break CL programs.
This is an example of such a case. Although CL users are told not to
directly change *TERMINAL-IO*, users of some CL implementations may invoke
system-dependent commands which change it. And when they do so, they
do not want their CL programs to break because those programs have made
unwarranted assumptions about the constant nature of *TERMINAL-IO*.
In fact, once more progress has been made in the window system arena,
we may even want to lift the restriction that *TERMINAL-IO* should
not change due to user programs. As such, it's best for now that programs
continue to assume that *TERMINAL-IO* might change, since some day it
might and it would be a shame for them not to be capable of accepting that
change.
∂29-Mar-87 2210 MURRAY%cs.umass.edu@RELAY.CS.NET MAPing Sequences
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Mar 87 22:10:15 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac14256; 30 Mar 87 1:13 EST
Received: from cs.umass.edu by RELAY.CS.NET id at23324; 30 Mar 87 1:08 EST
Date: Sun, 29 Mar 87 21:24 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: MAPing Sequences
X-VMS-To: CSNET%"common-lisp@su-ai.ARPA"
> It has not been established that it is a bug for sequence functions not
> to handle circular lists. There seems to be strong sentiment on both
> sides of this issue, and there is no clear statement on this in the
> manual. At some point the standardization committee will have to make a
> decision one way or the other.
Calling it a Bug was my own opinion. I should more careful, and I aplogize
for any confusion.
> If it were up to me (which it isn't) it would be an error to pass a
> circular list to any function that does not explicitly allow circular
> lists. I don't think the extra cost of handling this style is justified
> for most functions. Sequences should be finite.
> -- Scott
Extra cost for what? Using lists as sequences?
LENGTH and ELT are not constant-time operations on lists. AT LEAST FOR
THE MAPPING FUNCTIONS, it is a poor implementation which forces
every cons of a list to be looked at (paged in)
if they will never be used by the function since some other sequence
is shorter. It is equally poor to scan the first N-1 elements of
a list every time to get the Nth. Whether sequences can be
infinite or not, an inefficient implementation technique that doesn't
support them seems like a poor reason to not allow them.
Kelly Murray
∂30-Mar-87 0931 primerd!doug@enx.prime.pdn
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 09:30:58 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA04210@EDDIE.MIT.EDU>; Mon, 30 Mar 87 12:32:17 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA08877; Mon, 30 Mar 87 10:41:27 EST
Message-Id: <8703301541.AA08877@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 30 Mar 87 09:35:32 EST
To: COMMON-LISP@SAIL.STANFORD.EDU
From: primerd!DOUG@ENX.Prime.PDN
Date: 30 Mar 87 09:35:33 EST
To: commonlisp (common-lisp@sail.stanford.edu)
From: Doug Rand (DOUG@ENX.PRIME.COM) x4182 bldg 10
Date: 30 Mar 87 9:26 AM
Subject: Re: MAPing Sequences
>.. an inefficient implementation technique that doesn't support them
> seems like a poor reason to not allow them.
> Kelly Murray
How can one handle circular lists indescriminately in sequence
functions? It seems to me that at minimum the function must record or
mark each cons to avoid a recursive loop. Am I missing an obvious point?
I am curious to know by what technique one can do NTH without scanning the
list (excluding cdr-coded lists)?
Cheers,
Doug
∂30-Mar-87 1058 JAR@AI.AI.MIT.EDU almost scheme in common lisp
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 10:58:06 PST
Date: Mon, 30 Mar 87 14:01:36 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject: almost scheme in common lisp
To: common-lisp@SAIL.STANFORD.EDU, scheme@MC.LCS.MIT.EDU
Message-ID: <176048.870330.JAR@AI.AI.MIT.EDU>
I have written a macro package which implements Scheme, less general
tail-recursion and first-class continuations, in Common Lisp. It
appears to be effective at transforming any Common Lisp implementation
into an acceptable development environment for Scheme programs.
Loops written using LETREC, internal DEFINE, or "named LET" are
macroexpanded into an appropriate TAGBODY construct, but other than
that, tail recursion is only done at the whim of your particular CL
implementation.
Being a macro package and not a compiler or interpreter, continuations
also clearly can't work in general (unless, again, your CL just happens
to support them). Other incompatibilities with the "Revised↑3" Scheme
report are minor.
It's called "Pseudoscheme" and resides in
MC.LCS.MIT.EDU: "JAR;PSEUDO >"
The documentation is in
MC.LCS.MIT.EDU: "JAR;PSEUDO DOC"
I'll send it by electronic mail to those unable to FTP it. Please
send mail to INFO-CLSCHEME-REQUEST@MC.LCS.MIT.EDU if you start using it,
so you can stay up to date on improvements.
Feel free to redistribute it, but try to let me know if you do so.
The documentation file describes its peculiarities in somewhat more detail.
- Jonathan Rees
∂30-Mar-87 1144 Moon@STONY-BROOK.SCRC.Symbolics.COM Circular list implementation technique
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Mar 87 11:43:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 104510; Mon 30-Mar-87 14:28:32 EST
Date: Mon, 30 Mar 87 14:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Circular list implementation technique
To: primerd!DOUG@ENX.Prime.PDN
cc: COMMON-LISP@SAIL.STANFORD.EDU
In-Reply-To: <8703301541.AA08877@primerd.prime.com>
Message-ID: <870330142823.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 30 Mar 87 09:35:33 EST
From: primerd!DOUG@ENX.Prime.PDN
How can one handle circular lists indescriminately in sequence
functions? It seems to me that at minimum the function must record or
mark each cons to avoid a recursive loop. Am I missing an obvious point?
See the example code on page 265 of CLtL. This technique doesn't come for
free, but it's more efficient than some more obvious techniques.
∂30-Mar-87 1151 barmar@Think.COM *terminal-io*
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Mar 87 11:51:45 PST
Received: from plato by Think.COM via CHAOS; Mon, 30 Mar 87 14:51:39 EST
Date: Mon, 30 Mar 87 14:52 EST
From: Barry Margolin <barmar@Think.COM>
Subject: *terminal-io*
To: Sandra J Loosemore <sandra%utah-orion@cs.utah.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8703292147.AA00699@utah-orion.ARPA>
Message-Id: <870330145200.2.BARMAR@PLATO.THINK.COM>
Date: Sun, 29 Mar 87 14:47:49 MST
From: sandra%utah-orion@CS.UTAH.EDU (Sandra J Loosemore)
CLtL specifies that *standard-input*, *standard-output*, and friends should
initially be bound to synonym streams that pass everything on to *terminal-io*.
In the very next paragraph (p329), however, it says that the value of
*terminal-io* should never be changed. What is the point of introducing the
extra level of indirection? Is there some reason why *standard-input*
couldn't be initialized to the same stream as *terminal-io*?
-Sandra
-------
It says that no USER program should ever change the value of
*terminal-io*. *terminal-io* is not, however, a constant. Programs
internal to the implementation might have need to set or bind it.
Actually, I can think of reasons why a user program would have need to
set *terminal-io*. For instance, suppose you write a windowing package
in Lisp -- when changing windows you would generally set *terminal-io*
to the newly selected window, and all the synonym streams would follow
it over to the new window.
I interpreted that sentence about *terminal-io* as a warning to users
that if they are assigning to *terminal-io* they probably are doing the
wrong thing. There's a similar warning in the description of EVAL.
barmar
∂30-Mar-87 1346 barmar@Think.COM MAPing Sequences
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Mar 87 13:45:41 PST
Received: from plato by Think.COM via CHAOS; Mon, 30 Mar 87 16:45:07 EST
Date: Mon, 30 Mar 87 16:44 EST
From: Barry Margolin <barmar@Think.COM>
Subject: MAPing Sequences
To: primerd!DOUG@ENX.Prime.PDN
Cc: COMMON-LISP@sail.stanford.edu
In-Reply-To: <8703301541.AA08877@primerd.prime.com>
Message-Id: <870330164457.7.BARMAR@PLATO.THINK.COM>
Date: 30 Mar 87 09:35:33 EST
From: primerd!DOUG@ENX.Prime.PDN
To: commonlisp (common-lisp@sail.stanford.edu)
From: Doug Rand (DOUG@ENX.PRIME.COM) x4182 bldg 10
Date: 30 Mar 87 9:26 AM
Subject: Re: MAPing Sequences
>.. an inefficient implementation technique that doesn't support them
> seems like a poor reason to not allow them.
> Kelly Murray
How can one handle circular lists indescriminately in sequence
functions? It seems to me that at minimum the function must record or
mark each cons to avoid a recursive loop. Am I missing an obvious point?
Not obvious, but fairly well known. It is not necessary to mark every
element of a list in order to detect circularity. The easiest way I
know of to detect circularity (I think this is Plummer's algorithm) is
to scan the list simultaneously by ones and twos, i.e. (defun
circular-list-p (list)
(do ((l1 list (cdr l1))
(l2 (cdr list) (cddr l2))) ;not very robust, it'll
;lose on dotted lists
((or (endp l1) (endp l2)) nil)
(when (eq l1 l2)
(return t))))
This takes time linear in the length of the circularity plus the length
of the subsequence before the circularity begins, and constant space; I
don't know if a more efficient algorithm is known.
As for mapping functions, as long as you require that at least one of
the arguments be finite, they shouldn't have to "detect" circularities
at all. When one of their inputs runs out they should throw out of the
loop.
∂30-Mar-87 1428 EVAN@CSLI.Stanford.EDU NMAP
Received: from CSLI.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 14:28:18 PST
Date: Mon 30 Mar 87 14:28:45-PST
From: Evan Kirshenbaum <evan@CSLI.Stanford.EDU>
Subject: NMAP
To: common-lisp@Sail.Stanford.EDU
Message-ID: <12290604828.28.EVAN@CSLI.Stanford.EDU>
When the topic of destructive mapping was first brought up, I thought
"What a great idea, but why not just write a function to do it?".
So I did. My first attempt took about 5 minutes and looked like:
(defun map-into (res-seq fn &rest arg-seqs)
(let ((index 0))
(apply #'map
nil
#'(lambda (&rest args)
(setf (elt res-seq index)
(apply fn args))
(incf index))
arg-seqs)
res-seq))
This worked and was quite elegant, but had the disadvantage that its
performance on lists could be much worse than its performance on vectors
because elt could be implemented to search from the beginning of the list
each time. After thinking a bit, I made the following modifications:
(defun map-into (res-seq fn &rest arg-seqs)
(let ((rs res-seq)
(index 0))
(apply #'map
nil
(if (listp res-seq)
#'(lambda (&rest args)
(setf (car rs) (apply fn args))
(pop rs))
#'(lambda (&rest args)
(setf (elt res-seq index)
(apply fn args))
(incf index)))
arg-seqs)
res-seq))
This seems to handle the general case quite nicely and would seem to
generalize well into a macro for those of you who like them better. This
assumes that the result sequence is big enough to handle the result of the
map (although it can be too big with no problem). By the way, I also
(obviously) vote for MAP-INTO rather than NMAP.
evan
-------
∂30-Mar-87 1533 primerd!doug@enx.prime.pdn Computed goto's
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 15:33:22 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA11899@EDDIE.MIT.EDU>; Mon, 30 Mar 87 18:34:28 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA09659; Mon, 30 Mar 87 17:50:56 EST
Message-Id: <8703302250.AA09659@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 30 Mar 87 16:57:26 EST
Subject: Computed goto's
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 30 Mar 87 16:57:26 EST
Thinking about it there are times when one would like to do a computed goto.
I notice that (go tag) in tagbody is explicitly not calculated. For
maximum effect the computation should result directly in a dispatched
goto. One can get the effect of this by using lambda's in an array and
doing an array lookup but this is somewhat more expensive (?).
Any suggestions about this?
Doug (doug@enx.prime.com)
∂30-Mar-87 1602 DLA@DIAMOND.S4CC.Symbolics.COM Computed goto's
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 30 Mar 87 16:02:21 PST
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71984; Mon 30-Mar-87 19:00:48 EST
Date: Mon, 30 Mar 87 19:00 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: Computed goto's
To: primerd!DOUG@ENX.Prime.PDN
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8703302250.AA09659@primerd.prime.com>
Message-ID: <870330190048.5.DLA@LIMPKIN.S4CC.Symbolics.COM>
Date: 30 Mar 87 16:57:26 EST
From: primerd!DOUG@ENX.Prime.PDN
Thinking about it there are times when one would like to do a computed goto.
I notice that (go tag) in tagbody is explicitly not calculated. For
maximum effect the computation should result directly in a dispatched
goto. One can get the effect of this by using lambda's in an array and
doing an array lookup but this is somewhat more expensive (?).
Any suggestions about this?
Why not use CASE on the dispatching integer? A good compiler could
always turn it into a dispatch instruction if the hardware supports it.
∂30-Mar-87 1638 wahlster@ernie.Berkeley.EDU Remove from Mailing List
Received: from ERNIE.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 16:38:16 PST
Received: by ernie.Berkeley.EDU (5.57/1.23)
id AA23818; Mon, 30 Mar 87 16:39:27 PST
Date: Mon, 30 Mar 87 16:39:27 PST
From: wahlster@ernie.Berkeley.EDU (Prof. Wolfgang Wahlster)
Message-Id: <8703310039.AA23818@ernie.Berkeley.EDU>
To: common-lisp@sail.stanford.edu
Subject: Remove from Mailing List
Since I am leaving the States today, please remove me from
the mailing list. It's too expensive to send everything
to Germany.
Thanks
Wolfgang Wahlster
∂30-Mar-87 1642 barmar@Think.COM Computed goto's
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Mar 87 16:42:37 PST
Received: from plato by Think.COM via CHAOS; Mon, 30 Mar 87 19:43:05 EST
Date: Mon, 30 Mar 87 19:43 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Computed goto's
To: primerd!DOUG@ENX.Prime.PDN
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8703302250.AA09659@primerd.prime.com>
Message-Id: <870330194324.4.BARMAR@PLATO.THINK.COM>
Date: 30 Mar 87 16:57:26 EST
From: primerd!DOUG@ENX.Prime.PDN
Thinking about it there are times when one would like to do a computed goto.
I notice that (go tag) in tagbody is explicitly not calculated. For
maximum effect the computation should result directly in a dispatched
goto. One can get the effect of this by using lambda's in an array and
doing an array lookup but this is somewhat more expensive (?).
Any suggestions about this?
Doug (doug@enx.prime.com)
One could hope that a CASE statement in which all the test objects were
small fixnums would be compiled into a jump table. I just checked, and
Symbolics doesn't do this.
I don't think an array of compiled function objects should be
significantly more expensive than what you want, though. The only added
expense I can think of is that you have to push a stack frame to
transfer and you have to indirect through the lexical environment to
reference variables that would have been local.
I think it would be pretty easy to write a macro that does this. In
fact, I think this does a simple subcase:
(defmacro on-goto (key &body clauses) ;remember BASIC?
(let ((array (map '(array function)
#'(lambda (clause)
(compile nil `(lambda () . ,clause)))
clauses)))
`(funcall (aref ,array ,key))))
Well, it's not as easy as I thought -- the above macro doesn't do the
right thing with lexical variables in the clauses. But I'm pretty sure
it could be done....
barmar
∂30-Mar-87 1820 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Computed goto's
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 30 Mar 87 18:19:59 PST
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72018; Mon 30-Mar-87 21:18:44 EST
Date: Mon, 30 Mar 87 21:21 EST
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Computed goto's
To: Barry Margolin <barmar@Think.COM>, primerd!DOUG@ENX.Prime.PDN
cc: common-lisp@sail.stanford.edu
In-Reply-To: <870330194324.4.BARMAR@PLATO.THINK.COM>
Message-ID: <870330212134.2.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: Mon, 30 Mar 87 19:43 EST
From: Barry Margolin <barmar@Think.COM>
I don't think an array of compiled function objects should be
significantly more expensive than what you want, though. The only added
expense I can think of is that you have to push a stack frame to
transfer and you have to indirect through the lexical environment to
reference variables that would have been local.
And if one of the lexical references is a go tag itself, many
implementations will arrange to do a THROW to someplace in containing
tagbody which will just invoke another computed-go...
I think it would be pretty easy to write a macro that does this. In
fact, I think this does a simple subcase:
(defmacro on-goto (key &body clauses) ;remember BASIC?
(let ((array (map '(array function)
#'(lambda (clause)
(compile nil `(lambda () . ,clause)))
clauses)))
`(funcall (aref ,array ,key))))
Well, it's not as easy as I thought -- the above macro doesn't do the
right thing with lexical variables in the clauses. But I'm pretty sure
it could be done....
It's not a good idea to go off and call the compiler at macro expansion
time. I'm not sure the above could work in the interpreter if you were
able to fix the lexical reference bug. What about a computed-goto out
of range, which I think means fall-through? DLA was right: CASE on
integers and hope the compiler will notice all the bodies are GO
statements and do the right thing.
(defmacro on-goto (key &rest wheres)
`(case ,key
,@(do ((index 1 (1+ index)) ; fortrash 1 based?
(wheres wheres (cdr wheres))
(clauses '() (cons `(,index (go ,(car wheres))) clauses)))
((null wheres) (reverse clauses)))))
(on-goto foobar here there anywhere)
=> (CASE FOOBAR
(1 (GO HERE))
(2 (GO THERE))
(3 (GO ANYWHERE)))
∂30-Mar-87 2155 primerd!doug@enx.prime.pdn Computed goto's
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Mar 87 21:55:25 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA22162@EDDIE.MIT.EDU>; Tue, 31 Mar 87 00:56:41 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA10705; Tue, 31 Mar 87 00:50:19 EST
Message-Id: <8703310550.AA10705@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 31 Mar 87 00:36:09 EST
Subject: Computed goto's
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 31 Mar 87 00:36:09 EST
As is the case for others I have found that the CASE form will not be
'smart' enough. For one thing our compiler first macroexpands it into
a cascaded IF form (from which it would require inhuman intuition to
correctly transform it into a computed goto).
Doug
∂30-Mar-87 2301 Moon@STONY-BROOK.SCRC.Symbolics.COM Discussion of computed GO and CASE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Mar 87 23:00:54 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 105141; Tue 31-Mar-87 01:59:55 EST
Date: Tue, 31 Mar 87 01:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Discussion of computed GO and CASE
To: Common-Lisp@sail.stanford.edu
Message-ID: <870331015943.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Three remarks:
(1) It isn't necessarily true that an indexed jump is a faster
implementation of CASE than a series of conditional branches. It
depends on the number of clauses in the CASE statement, on the
particular machine architecture, and in many architectures on the
particular machine model. The minimum number of clauses for which an
indexed jump is preferable generally increases with the performance of
the machine, as more pipelining and branch prediction hardware is used.
(2) We would surely rather have our compilers optimize this than do it
ourselves, by writing different source code for different machines.
(3) If our compilers don't produce code that is as efficient as we would
like, we should change our compilers, not our language. The language
should only be changed when there is a widely-agreed-upon reason why the
language makes efficient compilation impossible; that is clearly not the
case here.
∂31-Mar-87 0635 DLA@DIAMOND.S4CC.Symbolics.COM Computed goto's
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 31 Mar 87 06:35:29 PST
Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72091; Tue 31-Mar-87 09:34:36 EST
Date: Tue, 31 Mar 87 09:34 EST
From: David L. Andre <DLA@DIAMOND.S4CC.Symbolics.COM>
Subject: Computed goto's
To: primerd!DOUG@ENX.Prime.PDN
cc: common-lisp@sail.stanford.edu, DLA@DIAMOND.S4CC.Symbolics.COM
In-Reply-To: <8703310550.AA10705@primerd.prime.com>
Message-ID: <870331093435.6.DLA@LIMPKIN.S4CC.Symbolics.COM>
Date: 31 Mar 87 00:36:09 EST
From: primerd!DOUG@ENX.Prime.PDN
As is the case for others I have found that the CASE form will not be
'smart' enough. For one thing our compiler first macroexpands it into
a cascaded IF form (from which it would require inhuman intuition to
correctly transform it into a computed goto).
Sorry, but I don't think common lisp should be designed around the
deficiencies of individual compilers. If a compiler doesn't have a
hook for transforming macros before they're expanded, then the problem
is in the compiler, not the language specification.
∂31-Mar-87 0830 shebs%utah-orion@utah-cs.arpa Computed goto's
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 08:30:46 PST
Received: by utah-cs.ARPA (5.31/4.40.2)
id AA24061; Tue, 31 Mar 87 09:33:31 MST
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA09932; Tue, 31 Mar 87 08:25:16 MST
Date: Tue, 31 Mar 87 08:25:16 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs)
Message-Id: <8703311525.AA09932@utah-orion.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Computed goto's
Just for the record, the PSL compiler does produce jump tables out of a
CASE, but there are so many restrictions (enough cases, consecutive small
integers, etc) that as far as I know jump tables only appear in type
dispatching code. Definitely not worth munging a language for...
stan
∂31-Mar-87 0850 gls@Think.COM MAPing Sequences
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 31 Mar 87 08:50:32 PST
Received: from feuerbach by Think.COM via CHAOS; Tue, 31 Mar 87 11:51:05 EST
Date: Tue, 31 Mar 87 11:51 EST
From: Guy Steele <gls@Think.COM>
Subject: MAPing Sequences
To: primerd!DOUG@ENX.Prime.PDN
Cc: COMMON-LISP@sail.stanford.edu
Message-Id: <870331115131.6.GLS@FEUERBACH.THINK.COM>
Date: 30 Mar 87 09:35:33 EST
From: primerd!DOUG@ENX.Prime.PDN
How can one handle circular lists indescriminately in sequence
functions? It seems to me that at minimum the function must record or
mark each cons to avoid a recursive loop. Am I missing an obvious point?
The technique is described in the form of a piece of code for
LIST-LENGTH on page 265 of CLTL.
--Guy
∂31-Mar-87 1202 Masinter.pa@Xerox.COM "computed goto"
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 Mar 87 12:00:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 31 MAR 87 10:46:39 PST
Date: 31 Mar 87 10:54 PST
From: Masinter.pa@Xerox.COM
Subject: "computed goto"
To: common-lisp@sail.stanford.edu
Message-ID: <870331-104639-2597@Xerox>
Common Lisp's equivalent for "computed goto" is FUNCALL--it lets you
compute where you want to go. The more classic form of computed goto in
fortran is useful primarily because of the inability to define lexically
nested functions.
∂31-Mar-87 1338 primerd!doug@enx.prime.pdn Thanks for all the help
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Mar 87 13:38:07 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA07717@EDDIE.MIT.EDU>; Tue, 31 Mar 87 16:39:27 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA12685; Tue, 31 Mar 87 16:32:51 EST
Message-Id: <8703312132.AA12685@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 31 Mar 87 14:30:06 EST
Subject: Thanks for all the help
To: common-list@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 31 Mar 87 14:30:07 EST
Really, I wasn't suggesting munging the language. In PL/1 there isn't an
explicit computed goto (well actually you can compute a label) but the
select statement is often optimized. I just wanted some opinion on how
to accomplish this is the compiler didn't optimize this.
Cheers,
Doug
∂02-Apr-87 1943 Masinter.pa@Xerox.COM compiler-warning-stream
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Apr 87 19:43:05 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 APR 87 19:13:54 PST
Date: 2 Apr 87 17:56 PST
From: Masinter.pa@Xerox.COM
Subject: compiler-warning-stream
From: (Patrick H Dussud <DUSSUD%Jenner@ti-csl.csnet>)
To: cl-cleanup@sail.stanford.edu
Message-ID: <870402-191354-1170@Xerox>
----- Begin Forwarded Messages -----
Return-Path: <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
Received: from RELAY.CS.NET by Xerox.COM ; 02 APR 87 11:34:26 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab23724; 2 Apr 87 14:27 EST
Received: from ti-csl by RELAY.CS.NET id aj01125; 2 Apr 87 14:19 EST
Received: from Jenner (jenner.ARPA) by tilde id AA22003; Thu, 2 Apr 87 12:46:12 cst
Message-Id: <2753376503-1199148@Jenner>
Date: Thu, 2 Apr 87 12:48:23 CST
From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
To: Larry Masinter <Masinter.PA>
Subject: output from the compiler(compiler-warning-stream)
Larry,
I think the proposal is sound, however as a corollary, dribble ought to
specify that *error-output* will also be rebound, so someone can do a
dribble to a log file, invoke his top-level build function ,walk away
and all the compiler, loader ... messages will go to the log file.
Patrick.
----- End Forwarded Messages -----
∂02-Apr-87 2235 ELIOT%cs.umass.edu@RELAY.CS.NET Clipping Output
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Apr 87 22:34:59 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae01039; 3 Apr 87 0:16 EST
Received: from cs.umass.edu by RELAY.CS.NET id bn04266; 3 Apr 87 1:13 EST
Date: Thu, 2 Apr 87 18:33 EDT
From: ELIOT%cs.umass.edu@RELAY.CS.NET
To: Common-Lisp@SAIL.STANFORD.EDU
Subject: Clipping Output
X-VMS-To: CSNET%"Common-Lisp@su-ai.arpa"
Is there any good way, preferably in FORMAT to
clip output longer than a specified length?
I am using FORMAT to create a string from
a list, but I only want the first 10 or 20 characters.
The effect I need is equivalent to:
(subseq (format nil "~a" XXX) 0 20))
but I would rather not do all the consing that
this implies.
In general, I would like to be able to specify
the maximum field width of most of the format
directives.
∂06-Apr-87 1112 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU Common Lisp symbols
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 11:12:12 PDT
Date: Mon 6 Apr 87 14:08-EDT
From: "Stephen E. Robbins" <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Common Lisp symbols
To: common-lisp@SAIL.STANFORD.EDU
The company I work for is just starting a large project
in Common Lisp. For portability, we'd like to create our
own special package into which we IMPORT the implementation's
Common Lisp and then EXPORT *exactly* the set of CLtL symbols
that make up common lisp. Our packages will then USE our
private CL package.
Does anyone out there have a list of the symbols in CLtL?
Or is this going to require going through the manual page
by page and figuring out what needs to be [im]ported?
-- Stephen
∂06-Apr-87 1436 Moon@STONY-BROOK.SCRC.Symbolics.COM Common Lisp symbols
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Apr 87 14:36:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110163; Mon 6-Apr-87 17:35:49 EDT
Date: Mon, 6 Apr 87 17:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Common Lisp symbols
To: Stephen E. Robbins <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: The message of 6 Apr 87 14:08 EDT from Stephen E. Robbins <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Message-ID: <870406173533.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon 6 Apr 87 14:08-EDT
From: "Stephen E. Robbins" <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
The company I work for is just starting a large project
in Common Lisp. For portability, we'd like to create our
own special package into which we IMPORT the implementation's
Common Lisp and then EXPORT *exactly* the set of CLtL symbols
that make up common lisp. Our packages will then USE our
private CL package.
Does anyone out there have a list of the symbols in CLtL?
Or is this going to require going through the manual page
by page and figuring out what needs to be [im]ported?
Most, but unfortunately not all, implementations of Common Lisp are
careful to make the package named LISP contain all and only the
CLtL symbols, and to put their own symbols into a package with
a different name. I think you will find an increasing number of
implementations conforming to this implementation as time goes by.
If you need to be portable to an implementation that has not been
this careful, you can get the list of symbols from one of the careful
implementations, rather than doing your own debugging of the typos
in the manual.
∂06-Apr-87 1638 primerd!doug@enx.prime.pdn Re: Common LISP Symbols
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 16:38:05 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA04667@EDDIE.MIT.EDU>; Mon, 6 Apr 87 19:40:07 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA03399; Mon, 6 Apr 87 16:49:40 EST
Message-Id: <8704062149.AA03399@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 06 Apr 87 15:49:53 EST
Subject: Re: Common LISP Symbols
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 06 Apr 87 15:49:53 EST
On page 181 of Steele this is (I think) addressed under the description
of the package 'lisp'. This seems to include only those symbols in CL.
There is another harder semantic problem for you though: what about
extensions to the functionality of the base CL functions? If your
CL allows (for example) circular sequences in the sequence functions, etc,
this will not flag the incompatibility.
Doug
∂06-Apr-87 1918 DALY@IBM.COM all symbols
Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 6 Apr 87 19:18:14 PDT
Date: 6 April 1987, 21:47:00 EDT
From: Timothy Daly <DALY@ibm.com>
To: common-lisp@sail.stanford.edu
Message-Id: <040687.214700.daly@ibm.com>
Subject: all symbols
to get a list of all of the symbols do
(do-symbols (x (find-package 'lisp)) (print (symbol-name x)))
and then sort the list and weed out the garbage. It takes about 1/2
hour to 1 hour. I used the index of Cltl. I should note that the
index is not complete so be careful to look up any misses in the
body of the text. I've done this for several implementations.
∂06-Apr-87 2236 MURRAY%cs.umass.edu@RELAY.CS.NET Clipping output
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Apr 87 22:36:03 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae20194; 7 Apr 87 1:17 EDT
Received: from cs.umass.edu by RELAY.CS.NET id be10571; 7 Apr 87 1:10 AST
Date: Mon, 6 Apr 87 15:46 EDT
From: MURRAY%cs.umass.edu@RELAY.CS.NET
To: common-lisp@SAIL.STANFORD.EDU
Subject: Clipping output
X-VMS-To: CSNET%"common-lisp@su-ai.ARPA"
> From: ELIOT%cs.umass.edu@RELAY.CS.NET
> Is there any good way, preferably in FORMAT to
> clip output longer than a specified length?
> ...
> The effect I need is equivalent to:
> (subseq (format nil "~a" XXX) 0 20)
> but I would rather not do all the consing that this implies.
> In general, I would like to be able to specify
> the maximum field width of most of the format directives.
The code below would truncate output with minimal consing (at least
close to a constant).
Of course, this only works for ONE call to FORMAT, and so you
would need to break down a format string
into separate calls to get the effect on more than one directive.
With all the other whiz-bang features of format, a max-width field is
probably not too much to ask for. Anybody have any idea how difficult
it would be to add it in?
- Kelly
(defvar *truncate-buffer* (make-array 200 ;; The bigger it is, less consing
:element-type 'string-char
:adjustable t
:fill-pointer 0))
(defun TRUNCATE-FORMAT (max-width stream format-string &rest format-args)
(setf (fill-pointer *truncate-buffer*) 0) ;; Start Empty
(with-output-to-string (string-stream *truncate-buffer*) ;; Cons a stream.
(apply #'format string-stream format-string format-args)) ;; Fill it up
(when (> (fill-pointer *truncate-buffer*) max-width) ;; Truncate
(setf (fill-pointer *truncate-buffer*) max-width))
(format stream "~A" *truncate-buffer*)) ;; Output
∂07-Apr-87 0003 masinter.PA@Xerox.COM time to reactivate cl-cleanup
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 00:03:11 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 APR 87 00:03:51 PDT
From: masinter.PA@Xerox.COM
Date: 6 Apr 87 23:03:13 PST
Subject: time to reactivate cl-cleanup
To: cl-cleanup@sail.stanford.edu
Message-ID: <870407-000351-1768@Xerox>
Folks,
We need to avoid getting into long periods of inactivity. We have a lot
to accomplish between now and the next meeting. We also all have other
commitments, and this will only work if we can maintain a fairly steady
flow of background work.
I think for us to have a reasonable set of proposals for the full
committee to vote on next meeting we need everyone on this distribution
list to basically volunteer to write up approximately one issue per
week, with the understanding that some will take longer, and others will
take less time.
I'm reluctant to arbitrarily assign issues to people, and would rather
that you volunteer for the ones that you want to work on. However, I'm
willing to try to assign things randomly if you think it would help get
things rolling.
Does anyone disagree with the scheduling? Have any alternative proposals
for how we might proceed?
If not, I'd like to hear from each and every one of you about what your
schedule might be in the next couple of months for truding through the
current issues, both the ones that we've discussed and the ones in the
issues file.
Please reply to the whole list.
Thanks,
Larry
∂07-Apr-87 0127 unido!gmdzi!jc@seismo.CSS.GOV Common Lisp symbols
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 7 Apr 87 01:27:45 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA15280; Tue, 7 Apr 87 04:28:36 EDT
Received: by unido.uucp with uucp;
Tue, 7 Apr 87 09:46:43 +0100
Received: by gmdzi.UUCP id AA01179; Tue, 7 Apr 87 08:07:53 -0100
Received: by gmdzi.UUCP id AA08673; Mon, 6 Apr 87 22:30:25 -0100
Received: by unido.uucp with uucp;
Mon, 6 Apr 87 21:37:26 +0100
Received: by seismo.CSS.GOV (5.54/1.14)
id AA27779; Mon, 6 Apr 87 14:47:38 EDT
Message-Id: <8704061847.AA27779@seismo.CSS.GOV>
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 11:12:12 PDT
Date: Mon 6 Apr 87 14:08-EDT
From: "Stephen E. Robbins" <unido!OZ.AI.MIT.EDU!STEVER@seismo.CSS.GOV>
Subject: Common Lisp symbols
To: common-lisp@sail.stanford.edu
Status: R
The company I work for is just starting a large project
in Common Lisp. For portability, we'd like to create our
own special package into which we IMPORT the implementation's
Common Lisp and then EXPORT *exactly* the set of CLtL symbols
that make up common lisp. Our packages will then USE our
private CL package.
Does anyone out there have a list of the symbols in CLtL?
Or is this going to require going through the manual page
by page and figuring out what needs to be [im]ported?
-- Stephen
∂07-Apr-87 0430 unido!gmdzi!jc@seismo.CSS.GOV Re: Common LISP Symbols
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 7 Apr 87 04:30:21 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA19026; Tue, 7 Apr 87 07:31:11 EDT
Received: by unido.uucp with uucp;
Tue, 7 Apr 87 12:30:12 +0100
Received: by gmdzi.UUCP id AA04138; Tue, 7 Apr 87 12:12:32 -0100
Received: by gmdzi.UUCP id AA03614; Tue, 7 Apr 87 11:34:16 -0100
Received: by unido.uucp with uucp;
Tue, 7 Apr 87 10:49:03 +0100
Received: by seismo.CSS.GOV (5.54/1.14)
id AA05878; Mon, 6 Apr 87 20:09:04 EDT
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Apr 87 16:38:05 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA04667@EDDIE.MIT.EDU>; Mon, 6 Apr 87 19:40:07 EDT
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA03399; Mon, 6 Apr 87 16:49:40 EST
Message-Id: <8704062149.AA03399@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 06 Apr 87 15:49:53 EST
Subject: Re: Common LISP Symbols
To: common-lisp@sail.stanford.edu
From: unido!primerd!DOUG@seismo.CSS.GOV
Date: 06 Apr 87 15:49:53 EST
Status: R
On page 181 of Steele this is (I think) addressed under the description
of the package 'lisp'. This seems to include only those symbols in CL.
There is another harder semantic problem for you though: what about
extensions to the functionality of the base CL functions? If your
CL allows (for example) circular sequences in the sequence functions, etc,
this will not flag the incompatibility.
Doug
∂07-Apr-87 0431 unido!gmdzi!jc@seismo.CSS.GOV Common Lisp symbols
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 7 Apr 87 04:31:18 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP
id AA19059; Tue, 7 Apr 87 07:32:11 EDT
Received: by unido.uucp with uucp;
Tue, 7 Apr 87 12:34:34 +0100
Received: by gmdzi.UUCP id AA04069; Tue, 7 Apr 87 12:09:30 -0100
Received: by gmdzi.UUCP id AA02687; Tue, 7 Apr 87 10:11:11 -0100
Received: by unido.uucp with uucp;
Tue, 7 Apr 87 01:29:31 +0100
Received: by seismo.CSS.GOV (5.54/1.14)
id AA03221; Mon, 6 Apr 87 18:10:43 EDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Apr 87 14:36:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110163; Mon 6-Apr-87 17:35:49 EDT
Date: Mon, 6 Apr 87 17:35 EDT
From: "David A. Moon" <unido!STONY-BROOK.SCRC.Symbolics.COM!Moon@seismo.CSS.GOV>
Subject: Common Lisp symbols
To: "Stephen E. Robbins" <STEVER@oz.ai.mit.edu>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: The message of 6 Apr 87 14:08 EDT from Stephen E. Robbins <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Message-Id: <870406173533.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Status: R
Date: Mon 6 Apr 87 14:08-EDT
From: "Stephen E. Robbins" <STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
The company I work for is just starting a large project
in Common Lisp. For portability, we'd like to create our
own special package into which we IMPORT the implementation's
Common Lisp and then EXPORT *exactly* the set of CLtL symbols
that make up common lisp. Our packages will then USE our
private CL package.
Does anyone out there have a list of the symbols in CLtL?
Or is this going to require going through the manual page
by page and figuring out what needs to be [im]ported?
Most, but unfortunately not all, implementations of Common Lisp are
careful to make the package named LISP contain all and only the
CLtL symbols, and to put their own symbols into a package with
a different name. I think you will find an increasing number of
implementations conforming to this implementation as time goes by.
If you need to be portable to an implementation that has not been
this careful, you can get the list of symbols from one of the careful
implementations, rather than doing your own debugging of the typos
in the manual.
∂07-Apr-87 0658 @SAPSUCKER.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM all symbols
Received: from [192.10.41.223] by SAIL.STANFORD.EDU with TCP; 7 Apr 87 06:58:35 PDT
Date: Tue, 7 Apr 87 09:38 EDT
From: hornig@QUABBIN.SCRC.Symbolics.COM
Sender: File-Server@QUABBIN.SCRC.Symbolics.COM
Subject: all symbols
To: DALY@ibm.com, common-lisp@sail.stanford.edu
In-Reply-To: <040687.214700.daly@ibm.com>
Message-ID: <870407093846.7.FILE-SERVER@SAPSUCKER.SCRC.Symbolics.COM>
As a check on all those who have "rolled their own" list of the symbols
in the LISP package, there should be exactly 775 of them.
∂07-Apr-87 0919 FAHLMAN@C.CS.CMU.EDU time to reactivate cl-cleanup
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 09:19:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 7 Apr 87 11:47:22-EDT
Date: Tue, 7 Apr 1987 11:47 EDT
Message-ID: <FAHLMAN.12292628888.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: masinter.PA@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: time to reactivate cl-cleanup
In-reply-to: Msg of 7 Apr 1987 03:03-EDT from masinter.PA at Xerox.COM
I'd like to try to clean up a bunch of the proposals already in the
pipeline, but in order to do that I need to access the most recent
versions. Not having easy access to these things since the last meeting
has been just enough of an obstacle to get me to do somethign else
instead. Where are these proposals currently stored and how do I access
them? I would need to get at things in plain-ASCII format, not full of
hairy formatting stuff that only Xerox editors can understand.
Once we've got the backlog under control, I could attack a handful of
small issues or a few larger ones. Do you have a menu of issues not
dealt with yet?
I'd like to put together a proposal for &more. It's not as urgent as
some other things, but I'd like to get it on the table and see if it
anyone else thinks it is a good idea.
I can spend a bit of time each day reacting to things produced by
others, and something like a day a week producing new proposals.
Obviously, if there's a flood of other proposals to study, I would have
less time to produce. Some things I can pass off to other CMU people.
I'll be totally unavailable (out of the country) April 21 - 29, and June
23 - July 8. This means that I will miss the Boston meeting,
unfortunately -- I'm hoping the department will send Rob Maclachlan in
my place.
-- Scott
∂07-Apr-87 0942 smh@EMS.MEDIA.MIT.EDU Re: all symbols
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 09:38:35 PDT
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA02759; Tue, 7 Apr 87 11:31:13 EST
Date: Tue, 7 Apr 87 11:31:13 EST
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8704071631.AA02759@EMS.MEDIA.MIT.EDU>
To: DALY@ibm.com, common-lisp@sail.stanford.edu,
hornig@QUABBIN.SCRC.Symbolics.COM
Subject: Re: all symbols
From: hornig@QUABBIN.SCRC.Symbolics.COM
As a check on all those who have "rolled their own" list of the symbols
in the LISP package, there should be exactly 775 of them.
I believe there should be 776. Symbolics Genera 7 does not export
LISP:SIZE, which is used in (DECLARE (OPTIMIZE SIZE)). In fact,
Symbolics may have acquired the error from the list we circulated some
time back, from which we subsequently learned SIZE was missing.
Steve Haflich
Franz Inc.
∂07-Apr-87 0953 @SAPSUCKER.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM Re: all symbols
Received: from [192.10.41.223] by SAIL.STANFORD.EDU with TCP; 7 Apr 87 09:53:05 PDT
Date: Tue, 7 Apr 87 12:53 EDT
From: hornig@QUABBIN.SCRC.Symbolics.COM
Sender: File-Server@QUABBIN.SCRC.Symbolics.COM
Subject: Re: all symbols
To: smh@EMS.MEDIA.MIT.EDU, DALY@IBM.COM, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8704071631.AA02759@EMS.MEDIA.MIT.EDU>
Message-ID: <870407125319.4.FILE-SERVER@SAPSUCKER.SCRC.Symbolics.COM>
Date: Tue, 7 Apr 87 11:31:13 EST
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
From: hornig@QUABBIN.SCRC.Symbolics.COM
As a check on all those who have "rolled their own" list of the symbols
in the LISP package, there should be exactly 775 of them.
I believe there should be 776. Symbolics Genera 7 does not export
LISP:SIZE, which is used in (DECLARE (OPTIMIZE SIZE)). In fact,
Symbolics may have acquired the error from the list we circulated some
time back, from which we subsequently learned SIZE was missing.
Steve Haflich
Franz Inc.
Where is SIZE mentioned? It's not in the description of OPTIMIZE.
∂07-Apr-87 1007 STEVER%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU DEFVAR semantics
Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 7 Apr 87 10:07:13 PDT
Date: Tue, 7 Apr 1987 13:04 EDT
Message-ID: <STEVER.12292642996.BABYL@MIT-OZ>
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
To: common-lisp@SAIL.STANFORD.EDU
Subject: DEFVAR semantics
Looking over page 68 of CLtL, I have a question about
DEFVAR:
From the description, it seems the (DEFVAR <variable>) should
never give <variable> any sort of value. It should simply
"proclaim <variable> to be special and may perform other
system-dependent \bookkeeping-actions/." Giving <variable>
a default value seems like more than simple bookkeeping.
Is this a reasonable interpretation?
- Stephen
∂07-Apr-87 1506 Masinter.pa@Xerox.COM Re: time to reactivate cl-cleanup
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 15:06:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 14:53:31 PDT
Date: 7 Apr 87 14:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: time to reactivate cl-cleanup
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Tue,
7 Apr 87 11:47 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870407-145331-2489@Xerox>
Here is my status list. I will mail out separate messages with the text
of all proposals, even those which have been sent before. In addition,
the documents I am maintaining are the "Format" document, and this
status.
Please pick a proposal that says "need volunteer" and volunteer. You can
volunteer in private or in public. If you want to volunteer for several
at a time or just one at a time, you pick.
I'll try to mail out the current status report weekly from now on.
Status as of 7-Apr-87
ADJUST-ARRAY-DISPLACEMENT (revision 1)
Received but not discussed.
Need volunteer to lead discussion, summarize positions.
COMPILER-WARNING-BREAK (revision 2)
Released.
Questions on interaction with condition proposal.
Defer to error/signal/condition committee?
COMPILER-WARNING-STREAM (Revision 3)
Released
Comment from Dussand at TI, forwarded to cl-cleanup, no response.
DEFVAR-INITIALIZATION (Revision 3)
Released
DO-SYMBOLS-DUPLICATES (Revision 1)
Received but not discussed
Need volunteer to lead discussion, summarize opinions.
ENVIRONMENT-ARGUMENTS (provisional title)
(this includes macro-function-environment, get-setf-method-environment)
Need volunteer to draft complete proposal, alternatives.
FLET-IMPLICIT-BLOCK (Revision 2)
Discussion & agreement on cl-cleanup.
Needs summary of discussion appended to "Discussion" section.
Need volunteer.
FORMAT-ATSIGN-COLON (Revision 3)
Released.
FORMAT-OP-C (revision 1)
Discussed and agreed, final form not yet available
(with Moon's amendment)
Need volunteer.
FUNCTION-TYPE (revision 2)
General agreement on basic proposal.
Wording to be worked out.
Need volunteer (RPG ?)
IF-BODY (revision 2)
General agreement to recommend against.
Final form not yet available.
Need volunteer.
IGNORE-ERRORS
Discussed and agreed, final form not yet available
(LMM: Some objections, defer to error/signal committee?)
Need volunteer.
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
Released
Should remove confusing "To further clarify: " which is
about INTERN and not IMPORT.
PEEK-CHAR-READ-CHAR-ECHO
Agreed to be controversial
Need volunteer to summarize positions.
PRINC-CHARACTER:WRITE-CHAR
Discussed and agreed, final form not yet available
(write-char choice)
Need volunteer.
PROMPT-FOR
Agreed to be controversial
Need volunteer to summarize positions.
REMF-DESTURCTION-UNSPECIFIED
Not discussed
Need volunteer to check over, lead discussion.
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
Tabled, a subset which deals with only those functions that
don't work in positions will be separated out.
Need volunteer.
SHARPSIGN-BACKSLASH-BITS
No general agreement (the meeting notes read "we cringed")
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-NUMBER
Discussed, without general agreement.
Need volunteer to summarize positions.
SHARPSIGN-PLUS-MINUS-PACKAGE
Discussed, without general agremenet.
Need volunteer to summarize positions.
TAILP-NIL
Received but not discussed
Need volunteer to lead discussion, summarize positions.
UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
Discussed and agreed, final form not yet available
(choice 1c & 2c)
Need volunteer.
∂07-Apr-87 1506 Masinter.pa@Xerox.COM Issue ADJUST-ARRAY-DISPLACEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 15:06:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 14:54:29 PDT
Date: 7 Apr 87 14:55 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: CL-CLEANUP@sail.stanford.edu
Message-ID: <870407-145429-2490@Xerox>
Status: Received but not discussed
Need volunteer to lead discussion, summarize positions
Revision 1:
Issue: ADJUST-ARRAY-DISPLACEMENT
Reference: Steele p.297
Category: Clarification
Edit history: Submission 15 may 86 (Steele's list, NGall@G.BBN.COM)
The interaction of ADJUST-ARRAY and displacement is unspecified, i.e.,
what happens when the array being adjust is displaced.
Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES
Suppose we are adjusting array A, which is perhaps displaced
to B before adjustment and perhaps to C after adjustment.
(1) Not displaced before or after. The dimensions of A are altered, and
the contents rearranged as appropriate. Additional elements of A are
taken from the :initial-element. The use of :initial-contents causes
all old contents to be discarded.
(2) Not displaced before, but displaced afterwards to C. As already
specified, none of the original contents of A appears in A afterwards,
but rather the contents of C without any rearrangement of C.
(3) Displaced beforehand to B, and afterward to C. As in case (2), no
contents of B appear in A afterward. If :DISPLACED-INDEX-OFFSET is not
specified in this case, it defaults to zero; the old offset (into B) is
not retained.
(4) Displaced beforehand to B, but not displaced afterward. A gets a
new "data region", and contents of B are copied into it as appropriate
to maintain the existing old contents; additional elements of A are
taken from the :initial-element. However, the use of :initial-contents
causes all old contents to be discarded.
!
Discussion:
Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 15 May 86 16:24:10 PDT
Date: 15 May 1986 19:26-EDT
Sender: NGALL@G.BBN.COM
Subject: adjusting displaced arrays
From: NGALL@G.BBN.COM
To: common-lisp@SU-AI.ARPA
Message-ID: <[G.BBN.COM]15-May-86 19:26:22.NGALL>
The following appears in Guy's list of `clarifications':
(*) 293 ...Add a function DISPLACED-ARRAY-P, which takes an array and
returns NIL and 0 if it is not displaced or the array displaced to and
the displaced-index-offset if it is displaced. These allow certain code
efficiencies, and also allow array displacement to be explained in terms
of Lisp primitives: (DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS)
(LABELS ((FOO (ARRAY INDEX)
(MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY)
(IF (NULL NEW-ARRAY)
(ROW-MAJOR-AREF ARRAY INDEX)
(MULTIPLE-VALUE-CALL #'FOO
NEW-ARRAY
(+ INDEX OFFSET)))))
(FOO ORIGINAL-ARRAY
(APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS)))) As a
bow to efficiency, note the fact that if array A is displaced to B with
offset M, and B is displaced to C with offset N, and B is not
adjustable, then DISPLACED-ARRAY-P of A might return either array B with
offset M or array C with offset (+ M N). This generalizes to chains of
non-adjustable arrays. ----------
I would like to add an additional (and I think stronger) argument for
DISPLACED-ARRAY-P. Someone in our group had the following type of
problem: Given a very long string (representing, say, a long report),
he wanted to be able to displace a char. string of length N (call it
N-char-string) (where 1 <= N <= 80) to the beginning of the
very-long-string, do some parsing of the N-char-string, and then ADJUST
the N-char-string to start where it had previously ended and to have a
new length. In other words, he wanted to slide this variable length
window over the very-long-string. Without DISPLACED-ARRAY-P, he is
forced to wrap a structure around the displaced-array to record the
original array the current offset, even though the displaced array
structure already contains this info!
I would suggest one minor change to DISPLACED-ARRAY-P, in the case that
it returns NIL, I suggest that it should return only that (and not
return the 0). The zero provides no information and does not seem to be
of any use.
---------- (*) 297 Here are the interactions of ADJUST-ARRAY with
displacement. Suppose we are adjusting array A, which is perhaps
displaced to B before adjustment and perhaps to C after adjustment. (1)
Not displaced before or after. The dimensions of A are altered, and the
contents rearranged as appropriate. Additional elements of A are taken
from the :initial-element. The use of :initial-contents causes all old
contents to be discarded. (2) Not displaced before, but displaced
afterwards to C. As already specified, none of the original contents of
A appears in A afterwards, but rather the contents of C without any
rearrangement of C. (3) Displaced beforehand to B, and afterward to C.
As in case (2), no contents of B appear in A afterward. If
:DISPLACED-INDEX-OFFSET is not specified in this case, it defaults to
zero; the old offset (into B) is not retained. (4) Displaced beforehand
to B, but not displaced afterward. A gets a new "data region", and
contents of B are copied into it as appropriate to maintain the existing
old contents; additional elements of A are taken from the
:initial-element. However, the use of :initial-contents causes all old
contents to be discarded. ---------- In case (3), what if (eq B C)?
(this would be the case in the sliding window above). Saying that "no
contents of B appear in A afterward" is not true.
-- Nick
!
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 15:26:44
PDT
Received: from Semillon.ms by ArpaGateway.ms ; 26 JUN 85 15:26:02 PDT
Date: 26 Jun 85 15:25 PDT
From: Fischer.pa@Xerox.ARPA
Subject: Adjustable and displaced arrays (summary)
To: Common-Lisp@SU-AI.arpa
Message-ID: <850626-152602-1271@Xerox>
Here is "my understanding" of adjustable and displaced arrays.
This is an "unproofed by the other participants" summary of a discussion
between: Moon@STONY-BROOK.SCRC.Symbolics.COM, fischer.pa,
Fahlman@CMU-CS-C, Greek@DEC-HUDSON, RAM@CMU-CS-C, GSB@MIT-MC
A simple implementation example of displaced arrays: a displaced array
keeps a pointer to the actual array that it is displaced to. Accesses
to such a displaced array must look down the chain of displacements to
make a reference. It is important that the behavior of this technique
be preserved. It becomes critical when, for instance, an array
somewhere in the chain of displacements is handed to adjust-array and
given a new displacement. Accesses must then follow the new chain. Your
mileage may vary, eg you can optimize this any way you please, most
commonly by encaching information in the array "header" about the
ultimate address and offset of the block of data being referenced. A
scheme to update the encached information is then called for (possibly
for the whole chain of displaced arrays).
adjust-array can alter the dimensionality and contents (or displacement)
of an array. It doesn't move elements around to preserve order. It
only copies elements if the array they are part of enlarges or shrinks*.
Here is an outline of the cases adjust-array handles:
If a displacement is given as an argument
then
set dimensions
set displacement else if the old array was displaced
then
copy the elements (shrink, enlarge or same size**)
set new dimensions else if new dimensions have same linear size as old
then
simply set dimensions else
; new dimensions with different linear size
copy elements to new size block.
Bear in mind that initial-element, initial-contents, and displaced-to,
are mutually exclusive. Completely new contents may be specified by
initial-contents. Gaps in a newly enlarged array may be initialized
with initial-element.
[*Note: CLtL specifically does not specify when an error should be
signalled if adjusting an array causes another array displaced to it to
have invalid linear size. This could be done at adjust-array time or
aref time. Seems to be your choice.]
[**Note: this interpretation of the case where a displaced array loses
its displacement is made arbitrarily. It is unclear from the text of
CLtL whether the elements should be copied into a new block to remove
the old displacement, or whether a blank storage block should be
created. The former seems somewhat more reasonable.]
(ron)
∂07-Apr-87 1506 Masinter.pa@Xerox.COM Issue COMPILER-WARNING-BREAK (Revision 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 15:06:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 14:57:40 PDT
Date: 7 Apr 87 14:58 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue COMPILER-WARNING-BREAK (Revision 2)
To: CL-CLEANUP@sail.stanford.edu
Message-ID: <870407-145740-2499@Xerox>
My summary message was wrong: COMPILER-WARNING-BREAK is NOT RELEASED.
Status: Not released. Questions on interaction with condition
proposal.
Defer to error/signal/condition committee?
Issue: COMPILER-WARNING-BREAK
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Revision 2 by cleanup committee 15-Mar-87 14:25:03
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not say
whether *BREAK-ON-WARNINGS* affects warnings output by the compiler. If
this is to be allowed, it should be an explicitly expressed part of the
contract.
Proposal (COMPILER-WARNING-BREAK:YES):
The definitions of COMPILE and COMPILE-FILE should state that these
functions are required to break on warnings if *BREAK-ON-WARNINGS* is
true (just as if it calls WARN).
Note: User interface commands provided by particular vendor
implementations which implicitly call COMPILE or COMPILE-FILE could bind
*BREAK-ON-WARNINGS* back to NIL if they felt it important to not break
for some reason relating to cultural compatibility. This would not
interfere with the proposed new semantics for the functions COMPILE and
COMPILE-FILE.
Rationale:
*BREAK-ON-WARNINGS* is defined to cause the debugger to be entered when
warnings occur. If the compiler is permitted to warn (separate ballot
item), the effect of this variable on compiler warnings should be nailed
down.
Current Practice:
I would guess that some compilers respect *BREAK-ON-WARNINGS* and others
probably do not.
Adoption Cost:
I assume this is easy to arrange for in all implementations.
Cost of not adopting this change:
Implementations that don't adopt this change will be awkward to use.
Benefits:
This would make the language definition more consistent by making it
less subject to special cases.
Conversion Cost:
Probably little or no user code would be affected by this change.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
KMP supports this change.
Some confusion about differences between compiler warnings and other
kinds of warnings.
Should there be a separate compiler-break-on-warnings?
Is this an environment issue?
∂07-Apr-87 1506 Masinter.pa@Xerox.COM Issue: COMPILER-WARNING-STREAM (Revision 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 15:06:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 15:05:18 PDT
Date: 7 Apr 87 15:04 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Revision 3)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870407-150518-2513@Xerox>
Status: Released
Comment from Dussand, forwarded to cl-cleanup, no response.
Need volunteer to respond to Dussand's comment.
Issue: COMPILER-WARNING-STREAM
References: COMPILE (p438), COMPILE-FILE (p439)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
Revision 2 at committee meeting 15-Mar-87 14:18:56
Revision 3 reformat by Masinter 15-Mar-87 17:42:10
Problem Description:
The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.
Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)
COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.
Rationale:
Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.
Current Practice:
Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.
Adoption Cost:
In most cases, the change to the compiler to redirect output is expected
to be very slight.
Benefits:
Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.
Conversion Cost:
Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.
Aesthetics:
Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.
Discussion:
This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.
The cleanup committee supports this change.
∂07-Apr-87 1525 Masinter.pa@Xerox.COM Issue: DEFVAR-INITIALIZATION (Revision 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 15:25:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 15:09:53 PDT
Date: 7 Apr 87 15:10 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Revision 3)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870407-150953-2529@Xerox>
Status: Released
Issue: DEFVAR-INITIALIZATION
References: DEFVAR (p68)
Category: CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/26/87
Revision 2 by cleanup committee 15-Mar-87 14:45:18
Revision 3 by Masinter (normalize format) 15-Mar-87
18:34:28
Problem description:
The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?
Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):
If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.
Rationale:
In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.
Current Practice:
Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.
Adoption Cost:
Some implementations suffer a minor incompatible change. The
modification to systems is presumably trivial.
Benefits:
It's sometimes useful to have the ability to declare a variable without
initializing it. More importantly, though, DEFVAR is used by lots of
users in every implementation and it deserves uniform treatment.
Conversion Cost:
It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.
Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.
Aesthetics:
No significant issues are obvious to me.
Discussion:
The cleanup committee supports this clarification.
∂07-Apr-87 1525 Masinter.pa@Xerox.COM Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 15:25:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 15:14:35 PDT
Date: 7 Apr 87 15:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DO-SYMBOLS-DUPLICATES (Revision 1)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870407-151435-2535@Xerox>
Status: Received but not discussed
Need volunteer to put proposal in standard format
Edit history: Revision 1
Issue: DO-SYMBOLS-DUPLICATES
Reference: Steele, p. 187
Category: Simple Clarification
Description:
The book does not specify whether do-symbols can repeat. Avoiding
duplicates in do-symbols in all cases is computationally prohibitive in
some implementations. The authors of the manual intended that
DO-SYMBOLS iterates over all symbols accessible to this package,
including ones that are inherited from other packages.
Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED
Add to the specification to DO-SYMBOLS a note that it may execute the
body more than once for some symbols.
!
Discussion:
04-Mar-85 0934 RAM@CMU-CS-C.ARPA do-xxx-symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 09:34:29
PST
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 4 Mar 85 12:33:31-EST
Date: Mon, 4 Mar 1985 12:33 EST
Message-ID: <RAM.12092370210.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc: common-lisp@SU-AI.ARPA
Subject: do-xxx-symbols
In-reply-to: Msg of 3 Mar 1985 21:43-EST from Charles Hedrick <HEDRICK
at RUTGERS.ARPA>
Date: Sunday, 3 March 1985 21:43-EST
From: Charles Hedrick <HEDRICK at RUTGERS.ARPA>
To: ram
Re: do-xxx-symbols
The definition of DO-SYMBOLS says that it iterates over all symbols
accessible in the specified package, and that it does each once.
The
term "accessible in" is ambiguous. The code I have from Spice simply
iterates over the externals and internals of that package. One could
also interpret that as including packages used by the specified
package.
In that case, some interesting code would be needed to prevent a
given
symbol from being used more than once, since if IMPORT was done, a
symbol could appear in several packages. Does Spice still make the
interpretation that DO-SYMBOLS looks only at the package specified?
Similarly, APROPOS talks about symbols "available in" a given
package.
The wording talks about inheritance paths, so the implication seems
fairly clear that APROPOS does look at used packages.
Even after staring at the manual, I was unable to determine what the
intent was. It is unfortunate that after spending N pages developing
the theory and terminology, the actual function description blows it.
The two possibilities are to iterate over all symbols available in the
package, or only over those present in the package.
If Do-Symbols is supposed to iterate over all symbols available in the
package, then it is clearly impractical to guarantee that each symbol is
only done once, so there probably should be a caveat similar to that for
Do-All-Symbols in the Do-Symbols description. I think that with some
imagination, one could read the statement that each symbol is done once
to mean that each symbol is done at least once.
There is another problem with this interpretation, though. Before you
can iterate over any symbol for a used package, you must check to see if
the symbol is shadowed in the inheriting package. This could cause a
substantial performance penalty in Do-Symbols, since it would be forced
to do a hashtable lookup for each inherited symbol iterated over. This
means that doing an apropos in any package using the lisp package would
require doing 1000 hashtable lookups.
On the other hand, the word accessible could be replaced with present,
and everyone would be happy. Apropos would have to be changed to do a
Do-External-Symbols on each used package, and would ignore details such
as shadowed symbols.
Rob
!04-Mar-85 1048 FAHLMAN@CMU-CS-C.ARPA do-xxx-symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 10:47:57
PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 4 Mar 85 13:46:53-EST
Date: Mon, 4 Mar 1985 13:46 EST
Message-ID: <FAHLMAN.12092383554.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA, Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: do-xxx-symbols
In-reply-to: Msg of 4 Mar 1985 12:33-EST from Rob MacLachlan <RAM>
I don't think that the term "accessible in" is ambiguous, given the
definition on page 172. Where is the ambiguity? So DO-SYMBOLS wants to
iterate over all of the internal and external symbols directly present
in the current package, and also those symbols that are present because
they are external in the packages used by the specified package.
I don't think we need to worry about eliminating duplicates that result
from explicit calls to IMPORT. That would entail a lot of extra
bookkeeping and would usually not be important. The business about
shadowing is a bit more complex. Technically, a symbol shadowed in
package P is not accessible in P, but again a lot of bookkeeping would
be required to eliminate these. Unless someone has a clever idea for
how to do this efficiently, we should probably revise the description of
DO-SYMBOLS to allow it to ignore this problem. In the reare case where
a user really cares, he can check for shadowed symbols himself. In any
event, the manual should be clarified on these two points.
In the description of APROPOS, the term "available in" is supposed to be
"accessible in", so the rules for DO-SYMBOLS should apply if the package
is specified, and DO-ALL-SYMBOLS if all packages are to be searched.
By the way, several groups have decided that the default for no package
specified is bogus, and that if no package is specified the user
probably should be given all symbols ACCESSIBLE IN the current package.
An argument of T could mean that you really do want to see ALL the
symbols, including internal compiler symbols, etc. Opinions?
-- Scott
!
04-Mar-85 1606 HEDRICK@RUTGERS.ARPA Re: do-xxx-symbols
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 16:06:25
PST
Date: 4 Mar 85 19:05:43 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: do-xxx-symbols
To: RAM@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Rob MacLachlan <RAM@CMU-CS-C.ARPA>" of 4 Mar
85 12:33:00 EST
My current implementation is the following:
DO-ALL-SYMBOLS - all symbols in all packages
DO-MOST-SYMBOLS - all symbols in all packages except not internals in
LISP or COMPILER (which I claim the user is not interested in
seeing in many cases)
DO-SYMBOLS - all symbols in the package mentioned
DO-ACCESSIBLE-SYMBOLS - all symbols in the package, and all externals
in used packages. No attempt to remove shadowed symbols.
APROPOS
if package is omitted or NIL: DO-MOST-SYMBOLS
if package is T: DO-ALL-SYMBOLS
otherwise: DO-ACCESSIBLE-SYMBOLS -------
04-Mar-85 1851 HEDRICK@RUTGERS.ARPA Re: do-xxx-symbols
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 18:50:55
PST
Date: 4 Mar 85 21:50:06 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: do-xxx-symbols
To: Fahlman@CMU-CS-C.ARPA
cc: RAM@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>"
of 4 Mar 85 13:46:00 EST
There are at least four reasons why the description of DO-SYMBOLS does
not appear to include symbols in used packages:
1) "do-symbols provides straightforward iteration over the symbols of a
package". Searching all the used packages is not straightforward
iteration over the package.
2) There is an implication that UNINTERN can be called to remove symbols
from the package. UNINTERN'ing a symbol in a used package does not
exactly remove it from the package under discussion.
3) It is said that every symbol is processed once. In DO-ALL-SYMBOLS
there is an explicit warning that symbols may occur more than once. The
implication is that this is not true for DO-SYMBOLS. If DO-SYMBOLS was
supposed to look at used packages, then the same warning would apply to
it.
4) DO-EXTERNAL-SYMBOLS says that it is like DO-SYMBOLS, but only the
external symbols of the specified package are used. The wording of
DO-EXTERNAL-SYMBOLS seems to imply even more clearly that only the
specified package is scanned, not any used packages. It also seems to
imply that DO-SYMBOLS does the same thing, but for both internal and
external symbols.
Can we get an authoritative statement about what is covered by
DO-SYMBOLS and DO-EXTERNAL-SYMBOLS, and about whether duplicates and
shadowed symbols should be removed? I think this question is separate
from the APROPOS question. APROPOS with no argument is documented as
using DO-ALL-SYMBOLS. But with an argument it is not said to use
DO-SYMBOLS. So it would be perfectly acceptable to say that DO-SYMBOLS
looks only at the symbols in a particular
package, whereas APROPOS following the used chain. (Indeed that is what
I have done for the moment.) -------
!04-Mar-85 2026 FAHLMAN@CMU-CS-C.ARPA do-xxx-symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Mar 85 20:25:46
PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 4 Mar 85 23:24:38-EST
Date: Mon, 4 Mar 1985 23:24 EST
Message-ID: <FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: do-xxx-symbols
In-reply-to: Msg of 4 Mar 1985 21:50-EST from Charles Hedrick <HEDRICK
at RUTGERS.ARPA>
Can we get an authoritative statement about what is covered by
DO-SYMBOLS and DO-EXTERNAL-SYMBOLS, and about whether duplicates and
shadowed symbols should be removed?
Well, I think that the machinery for issuing authoritative statements is
pretty rusty right now. I hope that we will soon have some sort of duly
constituted authority, but right now all we have is the ad hoc executive
committee of which I am the ad hoc chairman.
Hedrick's note points out that the description in the manual is
ambiguous at best. OK. I wrote most of that (with input from Moon and
Steele, among others) and I'm sure that DO-SYMBOLS was meant to include
symbols inherited from used packages. It never occurred to me that
explicit IMPORT statements could set up a situation in which a symbol
might show up twice unless you go to a lot of trouble to prevent this. I
also didn't think about shadowed symbols.
In my earlier note, I sent out my view of how to patch the existing
description. This is my view of "how it ought to be" rather than "what
the manual says". Does anyone object to adopting this as the "official"
interpretation? The only thing I'm uneasy about is letting DO-SYMBOLS
generate shadowed symbols, but I don't see any good alternative.
-- Scott
!07-Mar-85 2130 KMP@SCRC-STONY-BROOK.ARPA DO-SYMBOLS finding shadowed
symbols
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Mar 85
21:30:01 PST
Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with
CHAOS-MAIL id 192222; Fri 8-Mar-85 00:28:37-EST
Date: Fri, 8 Mar 85 00:29 EST
From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Subject: DO-SYMBOLS finding shadowed symbols
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>
Message-ID: <850308002930.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 4 Mar 1985 23:24 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
In my earlier note, I sent out my view of how to patch the existing
description. This is my view of "how it ought to be" rather than
"what
the manual says". Does anyone object to adopting this as the
"official"
interpretation? The only thing I'm uneasy about is letting
DO-SYMBOLS
generate shadowed symbols, but I don't see any good alternative.
I'm also quite uneasy about this shadowed symbols issue. I see two
situations:
The first is interactive. When working interactively, you resort to
mapping when the space of things you're frobbing is too large to do
manually. In that case, you want all the help you can get and writing
the code to keep out shadowed symbols may be something you forget or
find very hard to write
correctly the first time (and you may only get one chance, unless you're
very careful). Undoing an incorrect mapping operation involving INTERN
may be massively hard.
The second is non-interactive. There you have the time to write and
debug an algorithm, but you may not be thinking about the shadowed
symbol case and may forget to write it in because it doesn't occur in
the scenario you're thinking about or whatever ... so you release code
that mostly works but has a bug sitting in it just waiting to happen.
If you make DO-SYMBOLS find symbols that are technically not accessible,
you'd better document it well. But personally, I don't advise it, even
if it makes coding it much harder. Better you, the implementor, spend
the time doing it once right than users spend the time over and over
again correcting for your ... I was going to say laziness, but that's
obviously the wrong word for people like all the CL implementors are.
Nevertheless,
you get my point. "An ounce of prevention, ..." and all that.
As to worrying about duplicated symbols, that doesn't strike me as as
big a deal, though I'm open to arguments to the contrary. -kmp
!08-Mar-85 0827 FAHLMAN@CMU-CS-C.ARPA DO-SYMBOLS finding shadowed
symbols
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Mar 85 08:27:04
PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 8 Mar 85 11:26:08-EST
Date: Fri, 8 Mar 1985 11:25 EST
Message-ID: <FAHLMAN.12093406500.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: DO-SYMBOLS finding shadowed symbols
In-reply-to: Msg of 8 Mar 1985 00:29-EST from Kent M Pitman <KMP at
SCRC-STONY-BROOK.ARPA>
I've been having some second thoughts about shadowed symbols in
DO-SYMBOLS myself. It really is pretty dirty conceptually to have
DO-SYMBOLS supply anything that is not really accessible in the package.
I guess there are some ways that implementors could hack this without
incurring unacceptable costs. For example, we could set a bit
somewhere, either in the symbol itself or in the hash-table entry, for
any symbol that has ever been shadowed in any other package. For the
small minority of symbols with this bit set, we would have to do the
extra checking to make sure that it really is accessible; for all other
symbols, we could skip this. We wouldn't have to worry about un-setting
this bit if a symbol gets un-shadowed -- it's just a heuristic. There
are lots of variations on this theme. The point is that it need not
involve unacceptable overhead to eliminate shadowed symbols, though it
does make a bit of extra work for implementors. I guess I'd opt in this
case to keep the language clean rather than the implementation.
So my revised suggestion is that DO-SYMBOLS does provide all accessible
symbols including those inherited via USE-PACKAGE. It will present each
symbol at least once (may be more than once in cases of explicit
importantion), but will not present any symbols that are not really
accessible in the package in question due to shadowing.
-- Scott
!
19-Mar-85 0717 FAHLMAN@CMU-CS-C.ARPA DO-SYMBOLS: duplicates and
shadowings
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 07:17:43
PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 19 Mar 85 10:05:40-EST
Date: Tue, 19 Mar 1985 10:05 EST
Message-ID: <FAHLMAN.12096275453.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Jon White <JLW@SU-AI.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: DO-SYMBOLS: duplicates and shadowings
The Spice Lisp system has now been changed by Rob Maclachlan so that
DO-SYMBOLS does the right thing (according to my latest proposal):
inherited symbols are presented, there is no special effort to eliminate
duplicates, and shadowed symbols are eliminated. As I understand it,
the latter is accomplished by keeping track of which packages contain
*any* shadowed symbols, and for symbols exported by these packages doing
what amounts to a call to FIND-SYMBOL on each candidate. Rob tells me
that even when this extra checking is being done, it doesn't hurt us too
much in speed.
-- Scott
27-Mar-85 1807 Moon@SCRC-STONY-BROOK.ARPA do-xxx-symbols
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85
13:35:07 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with
CHAOS-MAIL id 204359; Wed 27-Mar-85 16:05:30-EST
Date: Wed, 27 Mar 85 16:06 EST
From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
Subject: do-xxx-symbols
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>,
Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>,
Charles Hedrick <HEDRICK@RUTGERS.ARPA>
cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA
In-Reply-To: <RAM.12092370210.BABYL@CMU-CS-C.ARPA>,
<FAHLMAN.12092383554.BABYL@CMU-CS-C.ARPA>,
The message of 4 Mar 85 19:05-EST from Charles Hedrick
<HEDRICK@RUTGERS.ARPA>,
The message of 4 Mar 85 21:50-EST from Charles Hedrick
<HEDRICK@RUTGERS.ARPA>,
<FAHLMAN.12092488741.BABYL@CMU-CS-C.ARPA>,
The message of 4 Mar 85 23:34-EST from Charles Hedrick
<HEDRICK@RUTGERS.ARPA>
Message-ID: <850327160624.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comment: Message remailed after delay caused by distribution list error.
Due to some kind of mail problem I didn't see this conversation until
today.
We take DO-SYMBOLS to mean to iterate over all symbols accessible to
this package, including ones that are inherited from other packages.
That seems like the most reasonable interpretation of what the manual
says. I agree with Scott that the authors of the manual never imagined
that other interpretations were possible.
We provide DO-LOCAL-SYMBOLS as an extension. It iterates over only
symbols present in the specified package.
Our DO-SYMBOLS has the usual bug with shadowed symbols: its iteration
includes symbols that would have been inherited had they not been
shadowed. I think it's clear that this is a bug and not an allowable
interpretation of the manual.
Our DO-SYMBOLS has the usual bug with unnecessarily imported or exported
symbols: its iteration sees a symbol more than once if that symbol is
imported even though it would have been inherited, or is exported from
two used packages. Perhaps this case is rare enough in practice, and
difficult enough to test for, that the manual should be changed to say
that a symbol can be seen more than once, as Scott suggested.
Of course, certain implementations of packages (ones that hash symbols
redundantly in every package that inherits them, so that INTERN need do
only a single hash lookup regardless of the length of the use-list)
would never encounter such bugs. Perhaps the language should be based
on such a simple implementation as a standard, and other implementations
that try to save space are responsible for not deviating from that
standard. Opinions?
∂07-Apr-87 1627 nelson%bach.DEC@decwrl.DEC.COM Number of Common Lisp symbols
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 16:27:04 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA07131; Tue, 7 Apr 87 15:27:50 PST
Message-Id: <8704072327.AA07131@decwrl.dec.com>
Date: Tuesday, 7 Apr 1987 13:29:50-PDT
From: nelson%bach.DEC@decwrl.DEC.COM (Beryl Elaine Nelson)
To: common-lisp@sail.stanford.edu
Subject: Number of Common Lisp symbols
VAX LISP has 775 symbols in the COMMON-LISP package.
Beryl
∂07-Apr-87 1741 Masinter.pa@Xerox.COM Issue: ENVIRONMENT-ARGUMENTS (Revision 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 17:41:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 17:42:10 PDT
Date: 7 Apr 87 17:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: ENVIRONMENT-ARGUMENTS (Revision 1)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870407-174210-2710@Xerox>
Status: In discussion
Merged from issues GET-SETF-METHOD-ENVIRONMENT (of 9 Jan 87),
MACRO-FUNCTION-ENVIRONMENT.
Needs a volunteer to work over the proposal further.
Issue: ENVIRONMENT-ARGUMENTS
References: GET-SETF-METHOD (p106), MACROLET (p144)
Category: CHANGE
Edit history: Revision 1 by KMP 02/26/87
Revision 2 by cleanup committee 15-Mar-87 14:45:18
Revision 3 by Masinter (normalize format) 15-Mar-87
18:34:28
Problem description:
If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g. (defmacro special-incf ...
(get-setf-method ...) ...)
then
(macrolet ((test (x) `(car ,x)))
(special-incf (test z)))
would not "see" the test definition.
Similarly, the macro function associated with a given symbol depends on
the lexical context of that symbol, and can differ inside a MACROLET
(which introduces lexical macros), or inside a FLET or LABELS (which
shadow macros). However, there is no way to account for this lexical
context in macros which know their environment (using the &ENVIRONMENT
argument) and which do their own macro expansion
Example:
(defmacro example (form &environment environment)
(let ((macro (macro-function (car form)))
(when macro .... (funcall *macroexpand-hook* macro form environment)
...)
Normally, the macro-function definition reflects the interpretation of
the FORM argument to EXAMPLE. However, within a MACROLET it does not.
Proposal (ENVIRONMENT-ARGUMENTS:ADD-ARGUMENTS):
Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, you get
the null lexical environment.
Allow DEFINE-SETF-METHOD to take an &ENVIRONMENT argument; i.e.,
"&ENVIRONMENT variable" can appear in the lambda-list subform
of a DEFINE-SETF-METHOD form analogous to its appearance in DEFMACRO.
Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.
Add an optional environment argument to MACRO-FUNCTION. If the argument
is not supplied, you get the null lexical environment. Otherwise, the
environment argument is used to determine the macro definition. SETF of
MACRO-FUNCTION and SYMBOL-FUNCTION is not permitted when two arguments
are specified, even if the value of the second argument turns out to be
NIL.
Clarify that it is an error to use FLET/LABELS/MACROLET on any of the
symbols defined in CLtL as designating special forms.
The intent of these changes is to allow MACROLET, FLET, and LABELS to
shadow a
SETF method; in other words, a SETF method applies only when the global
binding of the name is lexically visible.
Rationale:
The ommission of these facilities were an oversight in CL. Macro
environments cannot work "correctly" without them.
Current Practice:
Some Common Lisp implementations already have adopted this change.
Symbolics is already using an optional argument to GET-SETF-METHOD for
something else, and it is a documented interface. However, their
analysis is that it is not a serious incompatible change for their
users.
Adoption Cost:
the cost of adopting this change is small but non-zero: some
implementations must change their definitions
Benefits:
Users cannot portably write SETF of functions which have MACROLETs
without this change.
Conversion Cost:
this is an upward compatible change. However, implementations which did
not already take into account the lexical environment for SETF'd forms
might start working differently if the internal implementation of SETF
is changed.
Aesthetics:
Adding environment arguments to get-setf-method complicates it and its
callers.
Discussion:
There was at some time a notion that this could be removed if macrolet
was removed, but even without MACROLET, FLET needs to be able to shadow
macro environments.
In a message from Moon:
"I agree with this [adding an optional environment argument to
MACRO-FUNCTION], but for consistency I believe the same treatment should
be given to SPECIAL-FORM-P, to SYMBOL-FUNCTION, and to SYMBOL-VALUE."
Masinter disagrees: it should "be an error" to shadow a special form
using MACROLET, FLET, or LABELS. SYMBOL-FUNCTION and SYMBOL-VALUE are
only associated with run-time values, while MACRO-FUNCTION is required
for compile-time macros.
For completeness, here are some of the original messages which were part
of the discussion (should be condensed before distribution):
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 16 JAN 87 21:45:31 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16
Jan 87 21:43:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 45582; Sat
17-Jan-87 00:42:27 EST
Date: Sat, 17 Jan 87 00:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-FUNCTION-ENVIRONMENT, Message 1
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12270857798.BABYL@C.CS.CMU.EDU>
Message-ID: <870117004223.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 14 Jan 1987 09:35 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Date: Friday, 9 January 1987 20:43-EST
From: Masinter.pa at Xerox.COM
I approve of the general thrust of this, but it's incomplete. I think
it
would be better to vote on a more complete proposal than to address each
part separately. Details below.
Issue: (Steele, p. 144) The macro function associated with a given
symbol depends on the lexical context of that symbol, and can differ
inside a MACROLET (which introduces lexical macros), or inside a
FLET or
LABELS (which shadow macros). However, there is no way to account
for
this lexical context in macros which know their environment (using
the
&ENVIRONMENT argument) and which do their own macro expansion.
Example:
(defmacro example (form &environment environment)
(let ((macro (macro-function (car form)))
(when macro .... (funcall macro form) ...)
Aside: this example is incorrect, because the function returned
by macro-function requires two arguments (CLtL p.144). Also as a point
of esthetics it probably should use *macroexpand-hook*.
Normally, the macro-function definition reflects the interpretation
of
the FORM argument to EXAMPLE. However, within a MACROLET it does
not.
Classification: This is a mistake in CLtL.
Proposal MACRO-FUNCTION-ENVIRONMENT:ADD-ARG:
Add an optional environment argument to MACRO-FUNCTION. If the
argument
is not supplied, you get the null lexical environment. Otherwise,
the
environment argument is used to determine the macro definition.
I agree with this, but for consistency I believe the same treatment
should
be given to SPECIAL-FORM-P, to SYMBOL-FUNCTION, and to SYMBOL-VALUE.
It should be stated that SETF of MACRO-FUNCTION and SYMBOL-FUNCTION is
not permitted when two arguments are specified, even if the value of
the second argument turns out to be NIL. (Maybe I'm wrong here and
SETF should be allowed, but it should be stated that this does not
change the lexical structure of the program, it only substitutes one
binding for another existing binding in the same lexical contour,
and furthermore cannot mutate a MACROLET into a FLET or vice versa.)
I can't figure out whether CLtL intends to permit FLET/LABELS/MACROLET
to shadow global definitions of symbols as special forms. If it does
not, adding an environment argument to SPECIAL-FORM-P would be inutile.
CLtL p.57 says that anything described as a macro can be implemented as
a special form as long as a macro expander is provided; this implies
that if special forms cannot be shadowed, then macros cannot be shadowed
either. However, the discussion of this issue says that FLET and LABELS
can shadow macros, and presumably this was intended to include global
macros as well as local (MACROLET-defined) macros. It's clear that the
language is not very well-specified in this area. It would help if
there
was a clearer distinction between a symbol that names an operator and
the
operator object that is the definition of that symbol; I think CLtL was
a little too coy here. (An operator is a function, a macro, or a
"special form thing" (no name exists in CLtL for these; we call them
"primitive special operators", since macros are "special operators"
too.))
If no one else volunteers, I would be willing to write a proposal to
clarify this, based on what Symbolics' system does as a starting point.
It might take me 2 or 3 weeks to find the time to do it.
- - - - - - - - - - - - - - -
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 19 JAN 87 16:53:15 PST
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Jan 87
16:50:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 JAN 87 16:42:05 PST
Date: 19 Jan 87 16:45 PST
From: Masinter.pa
Subject: discussion: macro environments
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870119-164205-1133@Xerox>
I've not gotten any private messages on any of the topics; that is,
there've been no replies other than what's gone to cl-cleanup.
If we agree that several issues should be combined and considered as a
whole, so much the better.
One reason for separating out GET-SETF-METHOD-ENVIRONMENT and
MACRO-FUNCTION-ENVIRONMENT is that, while MACRO-FUNCTION currently works
as specified (i.e., the language in CLtL clearly states that it only
gets the *global* definition, while MACROEXPAND-1 and MACROEXPAND
themselves take environments), the specification for GET-SETF-METHOD is
currently inconsistent, e.g., the example on p 107 is incorrect because
it does not account for the environment of the SETF.
To put it another way, the cost of not adding the feature is different
for each of the proposals.
To put SYMBOL-FUNCTION and SYMBOL-VALUE into the same context is to
confound the lexical environments used in the interpreter (as passed,
e.g., by evalhook) and the lexical environments used by macro expansion
(as passed, e.g., to the &environment arguments of macros.) While both
of these (unspecified) pointers are "lexical environments", their use,
origin, and presumably internal structure are potentially radically
different.
I've more comments, but it will be late this week before I can send
them, and I thought I should get these notes out sooner.
- - - - - - - - - - - - - - - - - - - - - - - -
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 11 JAN 87 19:38:05 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jan 87
19:36:41 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 11 Jan 87 22:36:58-EST
Date: Sun, 11 Jan 87 22:36 EST
Message-ID: <FAHLMAN.12270213698.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: A comment on MACROLET...
In the issues file, it is pointed out in several places that the
"environment arg" issues would go away if we were to flush MACROLET.
Every time I start wrestling with explicit environment passing, I get
disgusted and start regretting that we ever let MACROLET in. That is
the source of these comments.
Masinter has pointed out that if we allow FLET and LABELS to shadow
macro definitions with function definitions, then various
macro-expanding forms will need to get at the environment even if
MACROLET goes away. So flushing MACROLET is not a solution, and clearly
there is no chance of flushing FLET and LABELS at this point.
We could, I suppose, forbid FLET and LABELS to shadow existing macros,
but that is even more of a crock than passing around environment
arguments. So unless someone can see a clever way out of this trap, I
guess I must withdraw my view that flushing MACROLET would be a good way
of eliminating explicit environment hackery. It seems we must devote
our attention to fixing up the environment stuff rather than getting rid
of it.
One clarification we might want to consider would be an explicit
statement that FLET and LABELS can be used to shadow a MACRO (but not a
special form?) with a function. I bet a lot of implementations have
overlooked this possibility. I think that Spice Lisp did.
The macro subcommittee might change all fo this beyond recognition, of
course, but it's our job to patch up the existing langauge.
-- Scott
∂07-Apr-87 1753 Masinter.pa@Xerox.COM Issue: FLET-IMPLICIT-BLOCK (Revision 3)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Apr 87 17:52:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 APR 87 17:49:30 PDT
Date: 7 Apr 87 17:50 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Revision 3)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870407-174930-2716@Xerox>
Status: Discussion & agreement on cl-cleanup.
Needs summary of discussion appended to "Discussion" section, rest of
discussion cut down.
Need volunteer.
Issue: FLET-IMPLICIT-BLOCK
Reference: CLtL p. 113, 67
Edit history: Revision 2 by cleanup committee 15-Mar-87 15:13:33
Revision 3 (move test case to issue section) 7-Apr-87 17:49:12
Status: tabled pending further thought of removing DEFUN implicit block
Description: Do flet, labels, and macrolet have an implicit block around
their bodies like the body of a DEFUN? CLtL is unclear.
Test case:
(DEFUN TEST ()
(FLET ((TEST (X) (IF X (RETURN-FROM TEST 4) 3)))
(LIST (TEST NIL) (TEST T))))
(TEST)
will return either (3 4) if this proposal is adopted, and might return 4
if an implementation did *not* add an implicit block.
Category: Ommission.
Proposal: FLET-IMPLICIT-BLOCK:YES
FLET, LABELS, and MACROLET have an implicit block around the body with
the same name.
Current Practice:
This does not generally reflect current practice. Several
implementations do not add the implicit block, others do.
Cost of adopting this change:
Small, since adding the implicit block is a simple extension for any
implementation.
Cost of not adopting the change:
Continued inconsistancy between DEFUN-formed functions and FLET defined
functions.
Cost of converting existing code:
Relatively small, in that it is unlikely that any code in a current
implementation that doesn't have an implicit block around FLET code
might also do a RETURN-FROM a block with the same name.
Discussion:
The goal is consistency between the behavior of global and local
definitions, to make transition between local and global definitions
easy. The alternative is to remove implicit blocks from DEFUN.
---------------------------------------------------------------------------
Page ???:
In addition to DEFUN, the following macros implicitly wrap a BLOCK
around their bodies: DEFMACRO, DEFSETF, DEFINE-SETF-METHOD, and DEFTYPE.
Also, LABELS, FLET amd MACROLET should wrap a block around the bodies of
the locally defined functions. Users are encouraged to create such
blocks in their own macros where a body and an obvious block-name are
present.
---------------------------------------------------------------------------
Several points and issues:
1. Presumably we want to address DEFMACRO, DEFSETF, DEFINE-SETF-METHOD,
and DEFTYPE at the same time as FLET, LABELS, and MACROLET? Do these
forms raise any issues that are not raised by the others? I don't see
any. Rob tells me that Spice Lisp already installs blocks on all of
these forms additional forms, though we apparently do not do this on
FLET, LABELS, and MACROLET.
2. Do we want to suggest in any new manual that users provide such
blocks for their own macros if they take an arbitrary body? (Presumably
the right way to handle this is for our committee to pass along a set of
non-binding suggestions to the drafting committee. This would be one of
them; the business about avoiding confusing uses of the word "intern"
would be another. That way these suggestions don't get lost, but we
don't have to worry about formal votes tying the drafting committee's
hands in the choice of language.)
3. In the ISSUES file, I say that I think I am opposed to this proposal
on efficiency grounds. I no longer believe this to be a serious
problem. In compiled code, there is no issue: blocks that are not
actually used can be eliminated. I was thinking that this would require
the interpreter to code-walk in and modify FLET, LABELS, and MACROLET
forms at defun time, but clearly this is not the right implementation
strategy. Instead one would modify FLET and friends to establish the
block upon entry. This slows down these forms in the interpreter a bit,
whether the block is used or not, but this slowdown in relatively rare
forms, interpreter only, should not hurt much.
4. Is there an issue here with tail-recursion? Could the presence of
these implicit blocks make it much harder to do tail-recursion
optimization? I don't see the problem now, but I have a note that
someone raised this issue in earlier discussions.
Date: Wednesday, 28 January 1987 10:58-EST
From: Rob MacLachlan <RAM>
To: Scott E. Fahlman <Fahlman>
Re: Issue: FLET-IMPLICIT-BLOCK, Version 1: Are functions defined by
In case nobody else answers, the issue with tail-recursion was
that Block in the interpreter cannot mindlessly push things on the
stack if tail recursion is to be preserved. Implementations that
always created catch frames for Block were finding that tail recursion
was being inhibited in Defun due to the implicit block. The fix is to
cons the necessary structure on the heap. Repeated consing can be
avoided by explicitly passing this "continuation" into tail-recursive
invocations of eval.
This issue is almost totally irrelevant in the current discussion,
since the implicit Defun block already causes these problems and
isn't going to go away.
Rob
∂07-Apr-87 2241 Hvatum.DLAB@MIT-MULTICS.ARPA NMAP innefficiency
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 7 Apr 87 22:41:03 PDT
Date: Wed, 8 Apr 87 01:38 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: NMAP innefficiency
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870408053838.361428@MIT-MULTICS.ARPA>
From: Steve Bacher (C.S.Draper Lab)
NMAP and MAP don't need to use LENGTH or ELT to process lists if the
compiler can determine that all the sequences passed to it are lists.
In this case, the lists can be CDR'd down in traditional LISP 1.5
fashion until one of the sublists is ENDP. If, on the other hand,
you wish to mix lists and sequences, you probably don't care much about
efficiency anyway.
Possible compiler transforms:
(map 'list fun list1 list2 list3) --->
(do ((g1 list1 (cdr g1))
(g2 list2 (cdr g2))
(g3 list3 (cdr g3))
(result '()))
((or (endp g1) (endp g2) (endp g3)) (nreverse result))
(push (funcall fun (car g1) (car g2) (car g3)) result))
(nmap rlist fun list1 list2 list3) --->
(do ((gr rlist (cdr gr))
(g1 list1 (cdr g1))
(g2 list2 (cdr g2))
(g3 list3 (cdr g3)))
((or (endp gr) (endp g1) (endp g2) (endp g3)) rlist)
(setf (car gr) (funcall fun (car g1) (car g2) (car g3))))
Of course, there are better ways of doing MAP than using NREVERSE,
but this is just so you can see what I have in mind.
This solution takes into account the case where the list to be updated
is shorter than any of the other argument sequences.
≠
∂07-Apr-87 2241 Hvatum.DLAB@MIT-MULTICS.ARPA Compiling CASE
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 7 Apr 87 22:41:22 PDT
Date: Wed, 8 Apr 87 01:39 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: Compiling CASE
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870408053906.850449@MIT-MULTICS.ARPA>
From: Steve Bacher (C.S.Draper Lab)
The question of CASE compiling into a computed GOTO uncovers an
interesting dilemma. Should the compiler have special knowledge
about certain forms which are normally macro calls, because it knows
that they can be compiled into particular machine-code sequences,
or should it always honor the macroexpansion? Consider the case
(n.p.i.) where the user provides an alternate macro definition for
his/her own use (possibly because he/she doesn't remember that
there already is a CASE macro).
This could affect a whole class of "non-special-forms", i.e. things
like AND, OR, COND, PROG, which are supposed to be macros in CL but
are generally special forms in (older?) LISP implementations, and
recognized by the compiler in order to generate optimal code. Or
should there be a class of "quasi-special-forms" which the compiler
may deal with on a basis similar to that of true "special forms"
so that the best code can get generated? Should it be "an error" to
redefine such macros?
After all, the rationale here is to keep the number of true
"special forms" to a small finite number to enable portable
code walking (not "portable-code" walking), though I don't wish
to open up THAT can of worms again. But if this means that the
compiler is constrained from doing clever things with AND, OR, or
CASE, is it worth it?
- SEB
≠
∂08-Apr-87 0059 a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Re: Common Lisp symbols
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 8 Apr 87 00:59:02 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ae08139; 8 Apr 87 3:51 EDT
Received: from utokyo-relay by RELAY.CS.NET id aa19343; 8 Apr 87 3:45 AST
Received: from tansei.u-tokyo.junet by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET])
id AA01168; Wed, 8 Apr 87 16:12:23 jst
Received: by tansei.u-tokyo.junet (4.12/6.2Junet)
id AA24015; Wed, 8 Apr 87 16:12:46+0900
Date: Wed, 8 Apr 87 16:12:46+0900
From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
Return-Path: <a37078@ccut.u-tokyo.junet>
Message-Id: <8704080712.AA24015@tansei.u-tokyo.junet>
To: Moon@SCRC-STONY-BROOK.ARPA, STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Subject: Re: Common Lisp symbols
Cc: common-lisp@SAIL.STANFORD.EDU
I found KCL dated Nov.4 has 858 symbols in LISP package.
∂08-Apr-87 0723 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM Compiling CASE
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 8 Apr 87 07:23:06 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 74771; Wed 8-Apr-87 09:52:56 EDT
Date: Wed, 8 Apr 87 09:56 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA, common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <870408053906.850449@MIT-MULTICS.ARPA>
Message-ID: <870408095640.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
The job of both the compiler and macros is to preserve the semantics of
the source code. Therefore, it doesn't matter if the compiler always
uses macro definitions or if it has its own knowledge of macros as
"special forms." Many implementations would be unduly hurt if the only
forms the compiler knew were special are the couple dozen listed on page
57. For example, the Symbolics implementation has very efficient
compilations for many of the multiple-value forms, which by strict
Common Lisp are macros.
Also see in the middle of page 57:
Conversely, an implementation is free to implement as a special form
any construct described herein as a macro if an equivalent macro
definition is also provided.
I believe the intent of this statement is that the interpreter and
compiler may use the special form definition and special knowledge,
respectively, for efficiency.
∂08-Apr-87 0808 smh@EMS.MEDIA.MIT.EDU all symbols
Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 08:07:40 PDT
Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA08402; Wed, 8 Apr 87 10:06:07 EST
Date: Wed, 8 Apr 87 10:06:07 EST
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Message-Id: <8704081506.AA08402@EMS.MEDIA.MIT.EDU>
To: hornig@QUABBIN.SCRC.Symbolics.COM
Cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: hornig@QUABBIN.SCRC.Symbolics.COM's message of Tue, 7 Apr 87 12:53 EDT
Subject: all symbols
From: hornig@QUABBIN.SCRC.Symbolics.COM
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
I believe there should be 776.
Where is SIZE mentioned? It's not in the description of OPTIMIZE.
My mistake -- I was confused by some old software, and didn't check
CLtL. SIZE should *not* be an external of package LISP.
With this correction, I agree that there should be exactly 775 symbols
exported from package LISP. Presumably our lists are the same ...
∂08-Apr-87 0844 las@bfly-vax.bbn.com "Compiling CASE"
Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 8 Apr 87 08:44:08 PDT
To: common-lisp@sail.stanford.edu
Cc: allen@bfly-vax.bbn.com
Subject: "Compiling CASE"
Date: 08 Apr 87 11:49:15 D (Wed)
From: las@bfly-vax.bbn.com
"Compiling CASE"
The problem cited recently regarding macros vs. special
forms contains some subtleties that need addressing. Certainly,
a compiler should be able to view a macro as a "special form"
for purposes of emitting efficient code. Sensing these is not user-visible,
and should be okay as long as the semantics of the language is not altered.
Problems arise when one uses code-walkers, or other code analyzers, that deliberately
expand macros in order to boil down all code to "the" small set of understandable special forms.
The program analyzer may do its transform, then compile the code. References to the original macro
will then most likely be lost.
In this case, the system in essence requires that such macros be expandable, AND that the
compiler be able to transform them for optimization. The two transforms may be very
different, so that compiling the macro-expanded code and directly compiling the macro reference
result in different emitted code.
Here are some alternatives to solving this problem; only the first appears to be in the
realm of a standards orginization:
1. Expand the set of special forms to include more of the built-in macros. Code walkers
would then obviously need work.
2. Require that all macro expansions be identical to the transforms performed by the
compiler. This, of course, is very hard to enforce since a compiler usually operates with
much more contextual knowledge than does a macro expander.
3. Ignore the problem. If a code-walker transforms code then compiles it, then it deserves
what it gets. Code walkers can optionally be improved to sense the "semi-special" forms.
The best solution, in my opinion, is (1), since it solves the problem completely:
there is no chance that different code sequences could be emitted due to a macro expansion,
thus retaining efficiency and avoiding subtle bugs. I realize that it is difficult to swallow
such a change, but it should be considered.
Note that the problem does not arise with functions, as they are of course not macro-expanded.
Thus, the compiler may transform them as it pleases and code-walkers are not affected.
Perhaps a study could be made to determine precisely which built-in macros are worth
making into special forms, thus reducing the size of the change. I would certainly vote for CASE
and friends.
- Larry Stabile
∂08-Apr-87 1003 barmar@Think.COM Compiling CASE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Apr 87 10:03:42 PDT
Received: from ubaldo by Think.COM via CHAOS; Wed, 8 Apr 87 13:03:42 EST
Date: Wed, 8 Apr 87 13:04 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Compiling CASE
To: Hvatum@mit-multics.arpa
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <870408053906.850449@MIT-MULTICS.ARPA>
Message-Id: <870408130439.7.BARMAR@UBALDO.THINK.COM>
Date: Wed, 8 Apr 87 01:39 EDT
From: Hvatum@mit-multics.arpa
From: Steve Bacher (C.S.Draper Lab)
The question of CASE compiling into a computed GOTO uncovers an
interesting dilemma. Should the compiler have special knowledge
about certain forms which are normally macro calls, because it knows
that they can be compiled into particular machine-code sequences,
or should it always honor the macroexpansion? Consider the case
(n.p.i.) where the user provides an alternate macro definition for
his/her own use (possibly because he/she doesn't remember that
there already is a CASE macro).
[...]
The compiler can have special knowledge of particular macros, as long as
it ignores this special knowledge if the user redefines the macros.
MIT-derived Lisp Machines also allow users to add to the compiler's
optimizations.
barmar
∂08-Apr-87 1231 shebs%orion@cs.utah.edu Re: Compiling CASE
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 12:31:46 PDT
Received: by cs.utah.edu (5.54/utah-1.0)
id AA26391; Wed, 8 Apr 87 13:34:10 MDT
Received: by utah-orion.ARPA (5.31/4.40.2)
id AA28963; Wed, 8 Apr 87 13:34:07 MDT
Date: Wed, 8 Apr 87 13:34:07 MDT
From: shebs%orion@cs.utah.edu (Stanley T. Shebs)
Message-Id: <8704081934.AA28963@utah-orion.ARPA>
To: common-lisp@sail.stanford.edu
Subject: Re: Compiling CASE
Just in case anybody was considering adding more special forms to CL, let me
vote NO. I would, however, support any proposals to eliminate some of the
existing special forms and make them macros...
stan
∂08-Apr-87 1403 primerd!doug@enx.prime.pdn Compiling CASE - back to the fray
Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 14:02:20 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id <AA29088@EDDIE.MIT.EDU>; Wed, 8 Apr 87 16:03:40 EST
Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail)
id AA08245; Wed, 8 Apr 87 13:59:10 EST
Message-Id: <8704081859.AA08245@primerd.prime.com>
Received: (from user DOUG) by ENX.Prime.PDN; 08 Apr 87 12:56:23 EST
Subject: Compiling CASE - back to the fray
To: common-lisp@sail.stanford.edu
From: primerd!DOUG@ENX.Prime.PDN
Date: 08 Apr 87 12:56:23 EST
I might note that the equivalent case in the PRIME PL/1 compiler
(select(value); when(1)...; when(2)...;) is essentially broken down
to the nested if type construct in the IL representation and then
optimized by the backend into a computed GOTO. This has the feature
that if it was 'nicer' to write the code as nested IFs then the code
will still be optimized.
- Doug Rand
∂08-Apr-87 1439 Mailer@XX.LCS.MIT.EDU Compiling CASE
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 8 Apr 87 14:38:51 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 8 Apr 87 17:36-EDT
Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 36912; 8 Apr 87 16:32:01-EST
Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 32361; 8 Apr 87 10:38:02-EDT
Date: Wed, 8 Apr 87 10:37 EDT
From: Don Morrison <dfm@JASPER.PALLADIAN.COM>
Subject: Compiling CASE
To: Hvatum@MIT-MULTICS.ARPA
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <870408053906.850449@MIT-MULTICS.ARPA>
Message-ID: <870408103703.5.DFM@WHITBY.PALLADIAN.COM>
Reply-To: Don Morrison <DFM%JASPER@LIVE-OAK.LCS.MIT.EDU>
Date: Wed, 8 Apr 87 01:39 EDT
From: Hvatum@MIT-MULTICS.ARPA
From: Steve Bacher (C.S.Draper Lab)
The question of CASE compiling into a computed GOTO uncovers an
interesting dilemma. Should the compiler have special knowledge
about certain forms which are normally macro calls, because it knows
that they can be compiled into particular machine-code sequences,
or should it always honor the macroexpansion? Consider the case
(n.p.i.) where the user provides an alternate macro definition for
his/her own use (possibly because he/she doesn't remember that
there already is a CASE macro).
This could affect a whole class of "non-special-forms", i.e. things
like AND, OR, COND, PROG, which are supposed to be macros in CL but
are generally special forms in (older?) LISP implementations, and
recognized by the compiler in order to generate optimal code. Or
should there be a class of "quasi-special-forms" which the compiler
may deal with on a basis similar to that of true "special forms"
so that the best code can get generated? Should it be "an error" to
redefine such macros?
After all, the rationale here is to keep the number of true
"special forms" to a small finite number to enable portable
code walking (not "portable-code" walking), though I don't wish
to open up THAT can of worms again. But if this means that the
compiler is constrained from doing clever things with AND, OR, or
CASE, is it worth it?
- SEB
Open compiling a macro isn't really any different in this respect than open compiling
an ordinary function like car or mapcar, which most implementations do for a great
many functions. The rational is that so long as the user hasn't declared a function
notinline and the open coded sequence does the same thing as the real function you're
well within your rights to open code it; the same follows for macros. Note that if
the open compiled version does the same thing as the macro, you can still code walk
(well at least that's the theory; I suspect how successful it is in practice depends
on exactly why you're code walking).
I wonder, however, if all implementations do the right thing if you declare a macro
which is treated specially as notinline?
∂08-Apr-87 1457 Masinter.pa@Xerox.COM Re: Compiling CASE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Apr 87 14:57:30 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 APR 87 14:58:28 PDT
Date: 8 Apr 87 14:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Compiling CASE
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Wed, 8 Apr
87 13:04 EDT
To: common-lisp@sail.stanford.edu
Message-ID: <870408-145828-1556@Xerox>
"Consider the case (n.p.i.) where the user provides an alternate macro
definition for
his/her own use (possibly because he/she doesn't remember that there
already is a CASE macro). ... This could affect a whole class of
"non-special-forms", i.e. things
like AND, OR, COND, PROG, ...."
"The compiler can have special knowledge of particular macros, as long
as
it ignores this special knowledge if the user redefines the macros."
It is an error to redefine *any* of the built-in symbols of Common Lisp,
whether they are macros, special forms, or functions.
Compilers can therefore assume anything they want about any of the
built-in symbols of Common Lisp, whether they are functions, macros, or
special forms, since their definition cannot legally be changed.
One might expect a good Common Lisp compiler to produce the same code
whether one used one of the built in macros or its macro expansion.
This is generally possible, although there are some cases where it is
difficult. Certainly the resulting code must be behaviorally equivalent.
∂09-Apr-87 0222 Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU Re: Compiling CASE
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 02:22:49 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 05:20-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 36999; 9 Apr 87 04:23:07-EST
Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 62920; Thu 9-Apr-87 05:16:24-EST
Date: Thu, 9 Apr 87 05:16 EDT
From: Randy%acorn@oak.lcs.mit.edu
To: Masinter.pa@Xerox.COM
Subject: Re: Compiling CASE
Cc: common-lisp@sail.stanford.edu
Date: 8 Apr 87 14:56 PDT
From: Masinter.pa@Xerox.COM
"The compiler can have special knowledge of particular macros, as long as
it ignores this special knowledge if the user redefines the macros."
It is an error to redefine *any* of the built-in symbols of Common Lisp,
whether they are macros, special forms, or functions.
Compilers can therefore assume anything they want about any of the
built-in symbols of Common Lisp, whether they are functions, macros, or
special forms, since their definition cannot legally be changed.
Is "it an error" to FLET them? If not, then the compiler has to be
smart enough to not insert the transforms it might have. Transforms
are a whole 'nother issue. They are arguably the best way to provide
system-dependent optimizations. It would be useful, however, for
people whose compilers use the transform abstraction to provide an
extension like a NO-TRANSFORM declaration or something similar to
this in cases where you know something the compiler doesn't. (Like
maybe in a case like this.)
Randy Haskins
Gold Hill Computers
∂09-Apr-87 0535 Randy%acorn%LIVE-OAK.LCS.MIT.EDU.#Chaos@XX.LCS.MIT.EDU all symbols
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 05:35:22 PDT
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Apr 87 08:33-EDT
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 37016; 9 Apr 87 07:36:27-EST
Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 62925; Thu 9-Apr-87 06:58:15-EST
Date: Thu, 9 Apr 87 06:58 EDT
From: Randy%acorn@oak.lcs.mit.edu
To: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
Subject: all symbols
Cc: hornig@QUABBIN.SCRC.Symbolics.COM, common-lisp@SAIL.STANFORD.EDU
Date: Wed, 8 Apr 87 10:06:07 EST
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
From: hornig@QUABBIN.SCRC.Symbolics.COM
From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich)
I believe there should be 776.
Where is SIZE mentioned? It's not in the description of OPTIMIZE.
My mistake -- I was confused by some old software, and didn't check
CLtL. SIZE should *not* be an external of package LISP.
Presumably, you were thinking of '(OPTIMIZE SPACE)
[the four optimizable quantities, according to Steele, are SPEED,
SPACE, SAFETY, and COMPILATION-SPEED. I assume that the long name
was given to the last one to discourage its use...
With this correction, I agree that there should be exactly 775 symbols
exported from package LISP. Presumably our lists are the same ...
(DEFUN EQ (X Y)
(OR (AND (LISTP X) (LISTP Y) (= (LENGTH X) (LENGTH Y)))
(= (SYS:%GET-PHYSICAL-ADDRESS X) (SYS:%GET-PHYSICAL-ADDRESS Y))))
;;; :-)
Random
∂09-Apr-87 0704 NGALL@G.BBN.COM Re: Compiling CASE
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:04:06 PDT
Date: 9 Apr 1987 10:01-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Compiling CASE
From: NGALL@G.BBN.COM
To: Masinter.pa@XEROX.COM
Cc: common-lisp@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM] 9-Apr-87 10:01:21.NGALL>
In-Reply-To: <870408-145828-1556@Xerox>
Date: 8 Apr 87 14:56 PDT
From: Masinter.pa@Xerox.COM
It is an error to redefine *any* of the built-in symbols of Common Lisp,
whether they are macros, special forms, or functions.
Could you please cite the CLtL passage that forbids such redefinition. I
couldn't find it.
-- Nick
∂09-Apr-87 0707 gls@Think.COM Re: Compiling CASE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:07:11 PDT
Received: from thorlac by Think.COM via CHAOS; Thu, 9 Apr 87 10:07:11 EST
Date: Thu, 9 Apr 87 10:08 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re: Compiling CASE
To: Masinter.pa@xerox.com, common-lisp@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870408-145828-1556@Xerox>
Message-Id: <870409100809.4.GLS@THORLAC.THINK.COM>
Date: 8 Apr 87 14:56 PDT
From: Masinter.pa@xerox.com
It is an error to redefine *any* of the built-in symbols of Common Lisp,
whether they are macros, special forms, or functions.
I can't find, offhand, where in CLtL it says that.
Can you give a reference? Or is this a proposed cleanup?
--Guy
∂09-Apr-87 0719 RAM@C.CS.CMU.EDU Compiling CASE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 07:19:37 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 9 Apr 87 10:20:32-EDT
Date: Thu, 9 Apr 1987 10:20 EDT
Message-ID: <RAM.12293137369.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Guy Steele <gls@THINK.COM>
Cc: common-lisp@SAIL.STANFORD.EDU, Masinter.pa@XEROX.COM
Subject: Compiling CASE
In-reply-to: Msg of 9 Apr 1987 10:08-EDT from Guy Steele <gls at Think.COM>
Date: Thursday, 9 April 1987 10:08-EDT
From: Guy Steele <gls at Think.COM>
To: Masinter.pa at xerox.com, common-lisp at sail.stanford.edu
Re: Compiling CASE
Date: 8 Apr 87 14:56 PDT
From: Masinter.pa@xerox.com
It is an error to redefine *any* of the built-in symbols of
Common Lisp, whether they are macros, special forms, or
functions.
I can't find, offhand, where in CLtL it says that.
Can you give a reference? Or is this a proposed cleanup?
This is part of my proposal to the compiler cleanup committee,
although I think others have arrived at the same interpretation
before. This really seems pretty obvious if you choose to make
"correct program" synonomous with "portable program", since programs
that attempt to redefine parts of the language are apt to break the
system, and in any case won't coexist in the same lisp environment.
Rob
∂09-Apr-87 0834 @DIAMOND.S4CC.Symbolics.COM:DCP@QUABBIN.SCRC.Symbolics.COM "Compiling CASE"
Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 9 Apr 87 08:34:00 PDT
Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 75189; Thu 9-Apr-87 11:33:20 EDT
Date: Thu, 9 Apr 87 11:33 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: "Compiling CASE"
To: las@bfly-vax.bbn.com, common-lisp@sail.stanford.edu
cc: allen@bfly-vax.bbn.com
In-Reply-To: The message of 8 Apr 87 11:49 EDT from las@bfly-vax.bbn.com
Message-ID: <870409113306.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM>
Date: 08 Apr 87 11:49:15 D (Wed)
From: las@bfly-vax.bbn.com
"Compiling CASE"
...
Here are some alternatives to solving this problem; only the first
appears to be in the realm of a standards orginization:
1. Expand the set of special forms to include more of the built-in
macros. Code walkers would then obviously need work.
For the simplest code walkers and for purity/minimality of the language,
I don't find this acceptable.
2. Require that all macro expansions be identical to the
transforms performed by the compiler. This, of course, is
very hard to enforce since a compiler usually operates with
much more contextual knowledge than does a macro expander.
I think it is impossible. The compiler doesn't necessary "transform" a
multiple-value-bind form into source code; it probably generates code
sequences for it directly.
3. Ignore the problem. If a code-walker transforms code then
compiles it, then it deserves what it gets. Code walkers can
optionally be improved to sense the "semi-special" forms.
Code walking should unduly affect performance, so I don't like your
second sentence. Your third sentence is the tip of an iceberg which I
discuss below.
The best solution, in my opinion, is (1), since it solves the
problem completely: there is no chance that different code
sequences could be emitted due to a macro expansion, thus retaining
efficiency and avoiding subtle bugs. I realize that it is difficult
to swallow such a change, but it should be considered.
...
I have another alternative, which I believe is both better and harder to
implement. The problem is, what is a code walker? There's been some
mumbling about portable code walkers, but do they really solve any
cross-machine problems? Do people use code walkers for analysis (in
which case you don't have to keep the macroexpansions) or for
substitution (in which case there may be a problem)?
My proposal is to figure the functional needs of a code walker, and
document the interface in CLtL'91. Each implementation would be
required to implement the code walker. Each person therefore wouldn't
have to write his/her own, and there wouldn't need to be a portable one
because there is a "standard." I propose that the
code-walker-in-the-sky be allowed to have special knowledge of CLtL
macros that are implemented as special forms. There would be a keyword
argument saying to use the macro expansions instead. This means you
don't lose the benefits of treating some macros as special forms, but
you have to make sure that the functional needs of the code walker are
still met. I don't think this is an impossible task.
I use the Symbolics code walker a moderate amount, and it has many of
the above properties. It does a pretty good job. I would classify it
as a prototype and a reference point; I have been hampered by it.
∂09-Apr-87 1117 sears%wrs.DEC@decwrl.DEC.COM Re-defining COMMON-LISP symbols
Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 9 Apr 87 11:17:05 PDT
Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
id AA27622; Thu, 9 Apr 87 10:18:01 PST
Message-Id: <8704091818.AA27622@decwrl.dec.com>
Date: Thursday, 9 Apr 1987 11:14:13-PDT
From: sears%wrs.DEC@decwrl.DEC.COM
To: common-lisp@sail.stanford.edu, sears%wrs.DEC@decwrl.DEC.COM
Subject: Re-defining COMMON-LISP symbols
I believe that attempts to redefine built-in parts of the system are
inherently implementation dependent. It would be a mistake to define
the behavior of doing so as part of the specification. LISP implementors
may be find it useful to do this in their development.
There is a closely related operation, which consists of defining a new
symbol of the same name as an existing symbol in COMMON-LISP, and
shadowing that symbol in some package of the users choice. This operation
is necessary, in my view, for defining new systems on top of COMMON-LISP.
A number of systems currently being built depend on this functionality.
Presently, there is no clear definition of how the compiler and interpreter
interact in the presence of operations such as the redefinition of, say,
CONS.
Extending the COMMON-LISP specification to clearly define this area would
be helpful for system builders who use this set of features.
/wrs
∂09-Apr-87 1154 FAHLMAN@C.CS.CMU.EDU Re-defining COMMON-LISP symbols
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Apr 87 11:53:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 9 Apr 87 14:53:47-EDT
Date: Thu, 9 Apr 1987 14:53 EDT
Message-ID: <FAHLMAN.12293187110.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: sears%wrs.DEC@DECWRL.DEC.COM
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Re-defining COMMON-LISP symbols
In-reply-to: Msg of 9 Apr 1987 14:14-EDT from sears%wrs.DEC at decwrl.DEC.COM
Obviously we need a clarification about whether you can redefine CONS
and friends, globally or with FLET/LABELS.
There is a closely related operation, which consists of defining a new
symbol of the same name as an existing symbol in COMMON-LISP, and
shadowing that symbol in some package of the users choice. This operation
is necessary, in my view, for defining new systems on top of COMMON-LISP.
A number of systems currently being built depend on this functionality.
I don't see any question here. MY-PACKAGE:CONS is a different symbol
from LISP:CONS, and you can give it whatever definition you want. This
doesn't even confuse macros, since they deal in symbols and not print
names.
-- Scott
∂09-Apr-87 1310 gls@Think.COM Re-defining COMMON-LISP symbols
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 9 Apr 87 13:10:07 PDT
Received: from feuerbach by Think.COM via CHAOS; Thu, 9 Apr 87 16:08:24 EST
Date: Thu, 9 Apr 87 16:09 EDT
From: Guy Steele <gls@Think.COM>
Subject: Re-defining COMMON-LISP symbols
To: Fahlman@c.cs.cmu.edu, sears%wrs.DEC@decwrl.dec.com
Cc: common-lisp@sail.stanford.edu, gls@think.com
In-Reply-To: <FAHLMAN.12293187110.BABYL@C.CS.CMU.EDU>
Message-Id: <870409160913.6.GLS@FEUERBACH.THINK.COM>
Date: Thu, 9 Apr 1987 14:53 EDT
From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
...
I don't see any question here. MY-PACKAGE:CONS is a different symbol
from LISP:CONS, and you can give it whatever definition you want. This
doesn't even confuse macros, since they deal in symbols and not print
names.
It's sort of like a neutron bomb:
Machines survive fine; only people are confused.
:-) --Q
∂09-Apr-87 1413 RWK@YUKON.SCRC.Symbolics.COM DEFVAR semantics
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 9 Apr 87 14:13:03 PDT
Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191488; Thu 9-Apr-87 16:58:30 EDT
Date: Thu, 9 Apr 87 16:57 EDT
From: Robert W. Kerns <RWK@YUKON.SCRC.Symbolics.COM>
Subject: DEFVAR semantics
To: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
cc: common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <STEVER.12292642996.BABYL@MIT-OZ>
Message-ID: <870409165750.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM>
Date: Tue, 7 Apr 1987 13:04 EDT
From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU
Looking over page 68 of CLtL, I have a question about
DEFVAR:
From the description, it seems the (DEFVAR <variable>) should
never give <variable> any sort of value. It should simply
"proclaim <variable> to be special and may perform other
system-dependent \bookkeeping-actions/." Giving <variable>
a default value seems like more than simple bookkeeping.
Is this a reasonable interpretation?
Yes.
∂10-Apr-87 0958 barmar@Think.COM Compiling CASE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 10 Apr 87 09:58:09 PDT
Received: from ignatius by Think.COM via CHAOS; Fri, 10 Apr 87 12:58:03 EST
Date: Fri, 10 Apr 87 12:58 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Compiling CASE
To: Don Morrison <DFM%JASPER@live-oak.lcs.mit.edu>
Cc: Hvatum@mit-multics.arpa, common-lisp@sail.stanford.edu
In-Reply-To: <870408103703.5.DFM@WHITBY.PALLADIAN.COM>
Message-Id: <870410125829.4.BARMAR@IGNATIUS.THINK.COM>
Date: Wed, 8 Apr 87 10:37 EDT
From: Don Morrison <dfm@jasper.palladian.com>
[...]
I wonder, however, if all implementations do the right thing if you declare a macro
which is treated specially as notinline?
I don't think it should be necessary to declare/proclaim a macro
notinline. For the macro to work at all, the defmacro must be seen by
the compiler before it tries to compile the use of the macro. I would
hope that the macro would be smart enough to notice that the user has
overridden the default definition.
barmar
∂11-Apr-87 0310 Hvatum.DLAB@MIT-MULTICS.ARPA Compiling CASE
Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 11 Apr 87 03:09:53 PDT
Date: Sat, 11 Apr 87 06:07 EDT
From: Hvatum@MIT-MULTICS.ARPA
Subject: Compiling CASE
To: common-lisp@SAIL.STANFORD.EDU
Message-ID: <870411100755.599053@MIT-MULTICS.ARPA>
From: Steve Bacher (Draper Lab)
In-Reply-To: DCP at SCRC-QUABBIN, DFM%JASPER at LIVE-OAK.LCS.MIT.EDU,
Masinter.pa at XEROX.COM
OK, the CLtL paragraph on page 57 is well known to me. But what if
the user redefines a macro, which is presumably legal? It may be
an error to redefine a special form, but what protection does the
LISP system have from the user doing it to a macro (or, better perhaps,
what protection does the user have from the LISP system ignoring such a
redefinition)?
Seems that the user will somehow have to know which macros are really
implemented as special forms, or at least special-to-compiler forms,
or else the compiler will have to be able to distinguish between
built-in macro definitions and user-provided macro definitions.
Probably this isn't that hard to do for an implementation developed
from scratch. In fact, a macro like CASE could expand alternately
into SYSTEM::INTERNAL-SPECIAL-FORM-CASE sometimes, and
SYSTEM::INTERNAL-MACRO-CASE other times.
To Don Morrison: What is the meaning of declaring a MACRO NOTINLINE?
CLtL doesn't imply that this is even possible.
(Which is not to say that CLtL implies that it ISN'T possible - I'm
being very careful with my wording here.)
Btw, looking at page 57 again I see that CLtL explicitly states that
the compiler may have special knowledge about forms like TYPECASE.
So I guess the only issues left are how to deal with user-provided
redefinitions, which should be properly handled by most implementations
in their own ways; and what code-walkers should do with them.
As far as what one code-walks for, there are two general areas:
(1) truly portable code-walking, e.g. looking for certain kinds of
function or variable references. Such walking needs to know
only about syntax, and cares little for how constructs are
actually implemented. Thus, it's OK to do maximal macroexpansion
and minimal special-form analysis.
(2) internal-use code-walking, e.g. the kind done by a phase of the
compiler. This is not limited to chunks of the compiler itself,
as various metasystems (e.g. source transforms) may wish to
code-walk to aid in compilation of a particular body of code.
Here, any special knowledge the compiler has about certain forms
must be retained, and it would be inadvisable to macroexpand such
forms.
Thing is, (2) is not limited to compiler hackers; users will wish to
provide their own functions to perform such code-walking feats.
Therefore, there ought to be a standard way of telling whether a
particular symbol names a form of which the compiler has special
knowledge. Perhaps COMPILER-SPECIAL-FORM-P?
(Of course, the question is then what to do with the damned thing...)
To Larry Masinter: Where is the quote in CLtL that supports your
statement that it is an error to redefine any of the built-in
functions or macros defined in Common LISP?
The package system will not protect Common LISP from having its
functions redefined, since a user who wants to define his/her own CAR
function will likely not call it USER:CAR; thus, since there is
already a CAR in the LISP package, that's the one that will get defined.
Maybe you think this is a silly example. What if the function was not
CAR, but (say) ENCODE-UNIVERSAL-TIME? It is reasonable to suppose
that Joe Lisphacker will not wish to look up every potential
function name to see if it is already defined. It is also not
reasonable for the compiler to reject this usage because it is an
error to redefine ENCODE-UNIVERSAL-TIME (and it is even worse for it
NOT to tell you because, after all, it's only "an error" and the user
doesn't have to be warned). It's also likely that the interpreter
will make different choices in the same matter, probably all bad ones.
What we wind up with here is COBOL LISP, with 775 reserved words,
subject to increase with the next edition of the reference manual.
≠
∂11-Apr-87 0740 RAM@C.CS.CMU.EDU Compiling CASE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Apr 87 07:40:17 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 11 Apr 87 10:39:54-EDT
Date: Sat, 11 Apr 1987 10:39 EDT
Message-ID: <RAM.12293665189.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: Hvatum@MIT-MULTICS.ARPA
Cc: common-lisp@SAIL.STANFORD.EDU
Subject: Compiling CASE
In-reply-to: Msg of 11 Apr 1987 06:07-EDT from Hvatum at MIT-MULTICS.ARPA
Date: Saturday, 11 April 1987 06:07-EDT
From: Hvatum at MIT-MULTICS.ARPA
Re: Compiling CASE
The package system will not protect Common LISP from having its
functions redefined, since a user who wants to define his/her own CAR
function will likely not call it USER:CAR; thus, since there is
already a CAR in the LISP package, that's the one that will get
defined.
This is what SHADOW is for.
[...] What if the function was not
CAR, but (say) ENCODE-UNIVERSAL-TIME? It is reasonable to suppose
that Joe Lisphacker will not wish to look up every potential
function name to see if it is already defined. [...]
It is reasonable to suppose that programmers won't want to look up
every symbol before they use it, but it is not reasonable to redefine
system functions. Programs that redefine system functions are not
portable for two reasons:
-- You might redefine a system facility that other parts of the
system depend on, for example, it you redefine
DECODE-UNIVERSAL-TIME, our compiler will not work.
-- Even if a program attempts to redefine a facility in an upward
compatible way, that program cannot coexist with other programs
that redefine the same facility an in incompatible upward
compatible way.
Just as in COBOL, the programming environment should provide ways to
prevent users from screwing themselves by redefining the system.
[...] It is also not reasonable for the compiler to reject this
usage because it is an error to redefine ENCODE-UNIVERSAL-TIME
[...]. It's also likely that the interpreter will make different
choices in the same matter, probably all bad ones.
This is another good reason to forbid redefinition of standard
functions and macros. If you allow redefinition, then you must
specify what the result is; this is difficult to do in the presence of
a variety of implementations of evaluation such as compilers and
interpreters.
Note on a point of dogma: it doesn't make any sense to say that a
construct is "Legal in Common Lisp but implementation dependent";
Common Lisp is nothing if not a specification of how to write portable
Lisp programs. In some cases it is reasonable for Common Lisp to
suggest standard mechanisms for accessing common implementation
features, but programs that rely on such constructs having any
particular effect are not portable, and thus not really Common Lisp
programs.
Rob
∂11-Apr-87 0810 RAM@C.CS.CMU.EDU Compiling CASE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Apr 87 08:09:57 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 11 Apr 87 11:09:51-EDT
Date: Sat, 11 Apr 1987 11:09 EDT
Message-ID: <RAM.12293670645.BABYL@C.CS.CMU.EDU>
From: Rob MacLachlan <RAM@C.CS.CMU.EDU>
To: common-lisp@SAIL.STANFORD.EDU
Subject: Compiling CASE
I think that this entire issue has been blown up out of porportion.
For one thing, there aren't many macros that there is a really good
reason for compiler to special-case: MULTIPLE-VALUE-BIND, OR and
xxxCASE are the main examples. It is feasible to avoid
special-casing even these.
Note also that writers of portable code walkers can anticipate that
certain macros may want to be special-cased by incorporating knowledge
about their syntax. The code walker doesn't need to do this, but the
resulting code may perform better in some implementations. The code
walker will still work even if the macro really is just a macro
The significance of code walkers has also been exaggerated. For one
thing, modern Lisp compilers tend not to use source code as the
internal representation, and their operation cannot really be modeled
as a source code walk. Given a sufficiently rich representation, many
things can be determined without actually grovelling the code.
Of course internal compiler representations are highly implementation
dependent, but this isn't necessarily a problem. One of the main
things that source code walkers have been used for is writing
"optimizing macros" for non-optimizing compilers. As long as the
compiler adequately optimizes the code, macros can expand in a
simple-minded way without understanding their arguments.
Rob
∂11-Apr-87 1547 masinter.PA@Xerox.COM redefining Common Lisp functions
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Apr 87 15:47:00 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 APR 87 15:45:36 PDT
From: masinter.PA@Xerox.COM
Date: 11 Apr 87 14:44:52 PST
Subject: redefining Common Lisp functions
To: common-lisp@sail.stanford.edu
Message-ID: <870411-154536-1554@Xerox>
Everyone (including Guy Steele!) seems to be challenging me to quote
"chapter and verse" in Guy Steele's book supporting my assertion that it
is an error to redefine any of the predefined Common Lisp functions and
macros. (The appropriate verse which claims that it is an error to
redefine one of the predefined special forms with DEFUN having been
found.)
Rather than attempting to divine meaning in CLtL, lets focus on some
related but different questions:
1. (Current practice) In your favorite Common Lisp implementation, which
of the predefined Common Lisp functions, macros, and special forms can
be safely redefined without causing unpredictable behavior somewhere
else in the system?
2. (Future standards) Which of the predefined Common Lisp functions,
macros, and special forms do you think *should* be redefinable.
3. (More constrained redefining) Presuming the CLOS, which of the
predefined Common Lisp functions should be specializable for
user-defined classes? How should such specialization affect the rest of
the behavior of Common Lisp?